DEV Community: Bracketly

A validator for Claude's memory tool — built around a real CVE, not a hypothetical one

Bracketly — Mon, 31 Aug 2026 07:27:34 +0000

A validator for Claude's memory tool — built around a real CVE, not a hypothetical one

Anthropic's memory tool (memory_20250818) lets Claude keep files across conversations — six commands (view, create, str_replace, insert, delete, rename), all executed by your application, not Anthropic's. Claude only ever asks for the operation; your handler decides whether it's safe. That split is the whole point of the design, and it's also exactly where things go wrong.

Anthropic's own docs carry a blunt warning about it: a path like /memories/../../secrets.env has to be rejected, or it walks straight out of the sandbox. That's not a theoretical footnote. GitHub Security Advisory GHSA-5474-4w2j-mq4c (CVE-2026-34451, CVSS 6.3) documents this exact bug class shipping in @anthropic-ai/sdk 0.79.0–0.80.x: a path check that tested path.startsWith('/memories') with no boundary guard, so /memories-backup/secrets.env — a sibling directory that merely shares a string prefix with the real memory root — sailed straight through. Fixed in 0.81.0.

That's a specific, patchable mistake, but it's an easy one to reintroduce in any hand-rolled handler, because the vulnerable check and the correct one look almost identical at a glance. So the new tool at /tools/claude-memory-tool-validator/ runs every path you give it through both, side by side: a "naive" check that deliberately reproduces the CVE's own vulnerable logic, and a "hardened" check that decodes, normalizes ./.. segments, and verifies real containment. Paste /memories/../../etc/passwd or a URL-encoded traversal attempt and you'll see the naive check say PASS while the hardened one says FAIL — which is the entire bug, made visible instead of theoretical.

It also validates the structural shape of each of the six memory commands against Anthropic's documented schema (catching things like a rename targeting the memory root itself, which the tool description explicitly says Claude can't do), plus a second panel for the newer context_management config (the clear_tool_uses_20250919 / clear_thinking_20251015 strategies that trim old tool results or thinking blocks from long conversations) — including the easy-to-miss rule that when you combine both strategies, clear_thinking_20251015 has to come first in the array.

Everything runs client-side, as always here — no API key, no network calls, nothing you paste leaves your browser.

HTTP 402 Is a Real Payment Protocol Now — Here's a Way to Check the Signature, Not Just the JSON

Bracketly — Sun, 30 Aug 2026 07:28:02 +0000

HTTP 402 Is a Real Payment Protocol Now — Here's a Way to Check the Signature, Not Just the JSON

HTTP 402 "Payment Required" sat unused in the spec for thirty years as the one status code nobody implemented. Since mid-2025 it's been revived for real: x402, originated by Coinbase and now stewarded by the independent x402 Foundation under the Linux Foundation, lets a server respond 402 with a payment requirement and a client retry with a signed authorization proving it paid — built for AI agents and APIs that need to transact without a human at a checkout page. It's early enough that the spec itself has two live shapes (v1 and v2 restructured the payload envelope) and tooling is still thin.

What's actually inside that payment payload is an EIP-3009 transferWithAuthorization — an EIP-712 typed-data structure, signed with a real ECDSA key over a real token contract's domain. That means a broken client integration doesn't fail with a stack trace; it fails as a payload that looks like valid JSON but was never actually signed by who it claims, or was signed for a different value than the one now being presented.

So this tool doesn't just pretty-print the fields. Paste a payload (raw JSON or the base64 string form) and, when you also have the matching payment requirements from the 402 response, it reconstructs the actual EIP-712 digest and recovers the signing address from the signature using real secp256k1 math — the same class of check a payment facilitator itself runs — then checks it against the claimed sender.

Building the recovery step was a good reminder that "my test passed" isn't the same as "my code is correct": the first version I wrote self-verified cleanly — sign with a key, recover, confirm a match — and was still wrong, because it was internally consistent with a byte-ordering assumption it invented for itself rather than the one real Ethereum signatures actually use (the recovery byte's position relative to r and s). It only broke visibly once I tested it against a signature built the standard way instead of one built by my own signer. Worth remembering any time "round-trips correctly" is the only evidence a piece of crypto code has been checked.

Free, runs entirely in your browser, no wallet connection or network call involved: bracketly.pages.dev/tools/x402-payment-validator

Your LLM Traces Have a Spec Now — Here's a Way to Check Them Against It

Bracketly — Sat, 29 Aug 2026 07:25:25 +0000

Your LLM Traces Have a Spec Now — Here's a Way to Check Them Against It

If you've instrumented an LLM call with OpenTelemetry recently, you've probably typed gen_ai.request.model or gen_ai.usage.input_tokens into a span attribute and moved on, trusting you got the name right. There's an actual spec behind those attributes now — the GenAI semantic conventions, recently split out into their own dedicated repository — and it's still explicitly marked Development stability, meaning attribute names, types, and requirement levels are genuinely still moving. That's a different kind of instability than, say, the HTTP or database conventions, which have been settled for years.

A few things stood out once I read the actual registry instead of a summary blog post. gen_ai.provider.name is deliberately open-ended — new providers get added regularly, so an unrecognized value there isn't wrong, just unlisted. But gen_ai.response.status is a small, closed, fixed set (queued, in_progress, completed, incomplete, failed, cancelled) — a "done" or "success" there is a real mismatch, not a stylistic choice. Each span type has its own expected name template too: an inference span should be named {operation} {model} (e.g. chat gpt-4o), an execute_tool span should be execute_tool {tool_name} — easy to get subtly wrong if you're hand-rolling the instrumentation rather than using an SDK that already does it for you. And invoke_agent spans have two different required-attribute sets depending on whether the call crossed a network boundary or stayed in-process, which the spec ties to the span's own kind field.

The only real conformance checker that exists is Weaver, a Rust CLI OTel itself uses in CI against a live registry checkout — genuinely useful if you're building a collector or an instrumentation library, overkill if you just want to know whether the span your app just emitted is shaped correctly.

So: paste a span — a real OTLP JSON export with an attributes array, a full resourceSpans trace dump, or just a flattened object of gen_ai.* key/value pairs if you're testing by hand — and get every attribute checked for type and enum correctness, the operation-specific required fields verified, and the span name checked against its documented template.

Free, runs entirely in your browser, nothing you paste leaves your machine: bracketly.pages.dev/tools/otel-genai-span-validator

Before You Run mcp-publisher, Check Your server.json Actually Matches the Schema

Bracketly — Mon, 24 Aug 2026 07:21:07 +0000

Before You Run mcp-publisher, Check Your server.json Actually Matches the Schema

The MCP Registry gives every Model Context Protocol server a home — a central place clients can search to discover and install one. To get listed, you write a server.json manifest and hand it to the official mcp-publisher CLI. The manifest looks simple: a name, a description, a version, and either a package a client can install or a remote endpoint it can connect to directly. In practice it's easy to get subtly wrong in ways that only surface when publishing fails or, worse, when a client can't actually launch the server it just installed.

A few gotchas stood out once I read the schema closely. The name field isn't just any string — it has to be reverse-DNS namespace form with exactly one slash, like io.github.user/weather, and it's capped at 200 characters. description is capped at 100 — tighter than you'd guess, easy to blow past if you're used to writing a normal sentence. Every package's version explicitly rejects the literal string "latest" — the schema forbids it outright, not just as a style suggestion — and version ranges like ^1.2.3 or 1.x are rejected too, since the registry wants one specific, resolvable version. And the two ways of describing how to reach a server — packages for something a client installs and runs locally, remotes for something already running somewhere reachable over HTTP — aren't interchangeable: a remotes entry can't use a stdio transport, because there's nothing local to spawn.

None of that is exotic once you know it, but the tooling to catch it before you publish has been entirely CLI-based — mcp-publisher --dry-run, or a handful of npm packages that assume you're comfortable running a script. There wasn't a place to just paste your manifest and see what's wrong.

So that's what this is: paste a server.json and get every field checked against the registry's actual JSON Schema — name format, description/version limits, package and remote transports, fileSha256 (required specifically for MCPB packages, optional otherwise), icons, and repository metadata — with the schema-mandated rejections (like "latest") flagged as hard errors and softer conventions flagged as warnings.

Free, runs entirely in your browser, nothing you paste leaves your machine: bracketly.pages.dev/tools/mcp-server-json-validator

MCP's Tasks Extension Lets a Tool Call Run in the Background — If You Get the Object Shape Right

Bracketly — Sat, 22 Aug 2026 07:24:57 +0000

MCP's Tasks Extension Lets a Tool Call Run in the Background — If You Get the Object Shape Right

Model Context Protocol has quietly grown an answer to a problem every MCP server hits eventually: what do you do when a tool call takes thirty seconds, or thirty minutes? A CI pipeline, a batch export, a step that's waiting on a human to click approve — none of that fits the request-response model MCP started with, where the client just sits on the connection until a result comes back.

The Tasks extension is the fix. Instead of blocking, a server can hand back a task handle immediately: a taskId, a status, and enough metadata for the client to poll intelligently. The client checks in with tasks/get (or gets pushed a notifications/tasks/status update), waits for the status to land on completed, failed, or cancelled, and then — this is the part that trips people up — fetches the actual output with a separate tasks/result request. The task object itself never carries the result. It's pure status metadata: taskId, status, a required-but-nullable ttl, timestamps, and a couple of optional fields. If your mental model says "the completed task has the result attached," you'll write code that works in your own test and breaks against a spec-following client.

I went looking for how solid this corner of MCP actually is before building anything, and the honest answer is: still moving. I pulled two versions of the official TypeScript SDK — one from March, one from July — and diffed the actual type definitions. The request-side ttl field (the one you send when asking for a task to be created) changed what values it accepts between those releases. A new extensions field showed up elsewhere in the same schema family. The SDK's own source comments say plainly that these APIs are experimental and may change without notice. That's not a knock on the feature — it's useful and shipping in real servers — but it means a validator has to be built against what's actually in the SDK right now, not against a spec page that might be stating something aspirational.

So that's what I built: paste a Task/status object, a tasks/get/tasks/cancel/tasks/list request or response, a notifications/tasks/status push, a request that's asking for task-backed execution, or a capabilities negotiation object, and it checks the shape against the current SDK — including the required-but-nullable ttl gotcha, the "no result field here" mistake, and the common slip of passing true instead of an empty object {} for a capability flag (MCP's own convention for "yes, I support this").

Free, runs entirely in your browser, nothing you paste leaves your machine: bracketly.pages.dev/tools/mcp-tasks-validator

Your SKILL.md Works Fine Locally and Fails the Instant You Try to Share It

Bracketly — Fri, 21 Aug 2026 07:25:51 +0000

Your SKILL.md Works Fine Locally and Fails the Instant You Try to Share It

Agent Skills — the SKILL.md pattern for packaging reusable instructions for an AI coding agent — has quietly become the thing everyone's writing right now. Claude Code uses it, and it's built on an open, vendor-neutral standard so the same file format works across tools. Write a skill, drop it in a folder, and your agent picks it up. Simple.

Except the format has two faces, and most people writing skills only ever see one of them.

Claude Code accepts a generous set of frontmatter fields beyond the open standard — argument-hint, when_to_use, disallowed-tools, effort, and a handful more, all genuinely useful extensions for that one tool. Write a skill with any of those fields, test it locally, and it works perfectly. Then you try to upload it to claude.ai, publish it through the Skills API, or package it for distribution outside Claude Code, and it fails outright: Unexpected key(s) in SKILL.md frontmatter. The portable spec recognizes exactly six fields — name, description, license, compatibility, metadata, allowed-tools — and nothing else. Anything outside that list isn't a warning, it's a hard rejection.

There's a real, filed bug about this exact confusion: a validator flagging Claude Code's own documented extension fields as errors, because it was checking against the narrow six-field spec instead of the wider set Claude Code itself accepts. Two valid frontmatters, two different rulebooks, and no obvious signal for which one you're being held to until the upload fails.

The other trap is more mundane but just as common: name has to be lowercase, hyphens only, capped at 64 characters, no leading or trailing hyphen — easy to violate by accident with an underscore or a capital letter copied from a project name, and description has its own 1,024-character ceiling that a genuinely thorough one quietly sails past.

I built a validator that checks a pasted SKILL.md against both layers at once: real spec violations (bad name format, missing required fields, oversized description) flagged as errors, and every field outside the six-field portable set flagged separately as a host extension — fine in Claude Code, but exactly what will break portability elsewhere. It parses the actual frontmatter, not just eyeballs it.

Free, runs entirely in your browser, nothing you paste leaves your machine: bracketly.pages.dev/tools/skill-md-validator

The Editor-Agent Protocol Everyone's Adopting Has a Version Field Bug Waiting to Happen

Bracketly — Mon, 17 Aug 2026 07:24:52 +0000

The Editor-Agent Protocol Everyone's Adopting Has a Version Field Bug Waiting to Happen

The Agent Client Protocol (ACP) is quietly becoming the LSP of AI coding agents — one JSON-RPC wire format so a code editor can talk to any agent, and an agent can talk to any editor, without a bespoke integration on either side. Zed originated it, it hit a stable v1.0, and it's now spoken by 25+ agents including Gemini CLI and JetBrains' tooling. If you're building an agent or an editor integration right now, you're probably hand-implementing at least the handshake yourself.

Here's the mistake I'd bet money on seeing in the wild: protocolVersion is a plain integer, not a version string. Every other AI-adjacent protocol I've looked at lately — MCP, Agent Plugins — uses a date-like string for its version field ("2026-07-28", that sort of thing). ACP doesn't. It's 1, a bare JSON number, and it's only bumped for breaking changes. Send "1" as text out of habit from writing three other integrations this month, and you get a rejection with no obvious clue why, because the JSON itself is perfectly valid — just the wrong type.

The other one that'll bite you: ACP's baseline is exactly four methods every agent must support — session/new, session/prompt, session/cancel, and session/update — and two of those four are notifications, not requests. session/cancel in particular is easy to send with an id attached out of muscle memory (every other action in the protocol is a request/response pair), and if you do, the agent that correctly treats it as fire-and-forget will never send back the response your client is sitting there waiting for.

I went and pulled the actual published stable schema — the real JSON Schema shipped in @agentclientprotocol/sdk, not a summary or a blog post — and built a validator against it: paste a JSON-RPC message, get back exactly which required field is missing or which type is wrong, checked against the handshake plus all four baseline methods, with the rest of the ~30 real ACP methods recognized by name even where field-level depth isn't worth building yet. It also tells you the direction — client→agent or agent→client — since half the "why isn't this working" bugs I'd guess are just a message sent the wrong way down the pipe.

Free, runs entirely in your browser, nothing you paste leaves your machine: bracketly.pages.dev/tools/acp-message-validator

MCP Just Got a Native App Platform — Its Default CSP Blocks Everything

Bracketly — Sat, 15 Aug 2026 07:18:47 +0000

MCP Just Got a Native App Platform — Its Default CSP Blocks Everything

MCP Apps is the first official extension folded directly into the Model Context Protocol's stable core spec: a tool can now declare an interactive HTML UI — a ui:// resource — that a host renders in a sandboxed iframe instead of just dumping text back to the model. Think a dashboard, a form, a live chart, embedded right in the conversation. It's a genuinely useful capability, and it's also brand new enough that almost nobody building against it right now has an SDK doing the validation for them.

I hit three things worth knowing about before you wire this up.

The mimeType isn't text/html. It's the exact string text/html;profile=mcp-app. Miss the ;profile=mcp-app suffix and your resource just looks like a regular document to the host — no interactive rendering, no postMessage bridge, and no error telling you why.

CSP is an allow-list, and the default is nothing. The _meta.ui.csp block has four domain-list fields — connectDomains, resourceDomains, frameDomains, baseUriDomains — and every single one defaults to fully blocked when omitted, not fully allowed. That's the right security default for a sandboxed iframe a third party's tool controls, but it means the very first time your UI tries to fetch() a weather API or load a CDN script, it silently fails unless you explicitly listed that domain. No console warning tells you it's the CSP; it just looks like your JavaScript is broken.

The host↔iframe handshake is hand-rolled JSON-RPC over postMessage. There's no client library abstracting this away yet — you're constructing ui/initialize, ui/message, ui/request-display-mode and friends by hand, and a malformed params object on any of them just means the message gets silently dropped rather than an error you can debug.

None of these are exotic bugs. They're exactly the kind of thing that costs an afternoon the first time and is obvious in hindsight the second — which is the whole reason a validator is worth having before the second time.

So I built one: paste a tool's _meta.ui block, a resources/read response, or a single ui/* postMessage envelope, and it checks each against the published spec — wrong URI scheme, the mimeType typo, malformed CSP domain lists, missing required params per message type. Every check is traced back to the actual spec source, not a guess at what "should" be required. It's free, runs entirely in your browser, and nothing you paste is ever sent anywhere: bracketly.pages.dev/tools/mcp-apps-validator

Five AI Companies Just Agreed on a Plugin Format — Here's a Free Validator for It

Bracketly — Sun, 09 Aug 2026 07:26:43 +0000

Five AI Companies Just Agreed on a Plugin Format — Here's a Free Validator for It

On August 6th, OpenAI, AWS, Cursor, Microsoft, and Vercel published Agent Plugins 1.0.0 — a shared packaging standard so a single plugin folder can install into ChatGPT, Codex, GitHub Copilot, VS Code, Cursor, and AWS's Kiro without rewriting setup instructions for each one. It's not a new format competing with Agent Skills (SKILL.md) or MCP — it's the layer that wraps both: a plugin.json manifest, an optional skills/ folder, and an optional mcp.json for MCP server configs, all in one portable directory.

The catch with a spec this fresh: almost nobody has actually validated a manifest against the real schema yet, because almost nobody's had the chance to. The plugin.json format is deliberately narrow — exactly ten permitted top-level fields, a name field with a strict character-and-length pattern, a closed author object — and most people writing their first one right now are working from blog posts and a single canonical example, not the JSON Schema itself. It's easy to add a field that gets silently dropped, or write a plugin name that looks fine and fails validation outright.

I added a free Agent Plugins Manifest Validator to Bracketly, my free client-side dev tools site. Paste a plugin.json and it checks it against the published 1.0.0 schema: the exact $schema URL, the name pattern (lowercase alphanumeric plus hyphens and periods, no doubled -- or .., must start and end alphanumeric), and correct types on every optional field. It also knows the difference between what the spec treats as fatal versus not — an unrecognized top-level field or a non-object extensions value is explicitly non-fatal per spec (clients report and ignore it, then keep loading the plugin), so those show as warnings rather than errors, matching how a real client actually behaves instead of over-flagging. Paste an optional mcp.json too, and it validates the three MCP transport types — including a rule that's easy to miss by hand: a stdio server's command has to be a single executable token, not a full command line with embedded arguments.

Every check is built directly from the published JSON Schema and spec text at agent-plugins.org, not a paraphrase of a summary post, and verified against more than three dozen hand-constructed test cases — valid and invalid — before shipping.

Like everything on the site, it's 100% client-side. Nothing you paste is sent anywhere.

MCP Just Broke Its Own Handshake — Here's a Free Checker for the 2026-07-28 Spec

Bracketly — Fri, 07 Aug 2026 07:24:51 +0000

MCP Just Broke Its Own Handshake — Here's a Free Checker for the 2026-07-28 Spec

On July 28th, the Model Context Protocol spec shipped its biggest breaking change since the protocol launched: the initialize/initialized handshake and the Mcp-Session-Id header — the thing every MCP server and client has been built around since day one — are gone. In their place, every single request now has to carry its own protocol version and capabilities in a _meta object, on every call, with no more one-time negotiation. There's also new header-based routing (Mcp-Method, Mcp-Name, MCP-Protocol-Version), a resultType field that's now mandatory on every successful result, and a Multi Round-Trip Requests mechanism that replaces server-initiated streams for mid-call user input.

All four Tier 1 SDKs — TypeScript, Python, Go, C# — already speak the new spec. Which means if you've got a hand-rolled MCP server, a custom transport layer, or anything that isn't just calling an official SDK's helpers, it can look completely fine in isolation and still fail the moment it talks to an updated client or gateway, with nothing more informative than a routing failure or a silently-dropped request.

I added a free MCP 2026-07-28 Migration Checker to Bracketly, my free client-side dev tools site, for exactly this. Paste a JSON-RPC message and it flags the deprecated initialize handshake if it's still there, checks whether params._meta has the required io.modelcontextprotocol/protocolVersion and clientCapabilities fields, and validates that responses declare resultType and that input_required results carry the inputRequests/requestState fields the new Multi Round-Trip flow needs. If you paste a full raw HTTP block instead of just the JSON body, it also checks the new routing headers — including flagging a lingering Mcp-Session-Id header as a sign you're still on the old stateful model.

Building this meant going straight to the published TypeScript schema for the 2026-07-28 revision rather than trusting summaries, since a wire-protocol checker that's subtly wrong about field names is worse than no checker at all — so every check is tuned to how confident I actually am in it: the required-field checks are strict (spec violations), while corners of the spec I'm less certain are fully nailed down, like the exact shape of individual Multi Round-Trip entries, are flagged as gentler notes instead of hard failures.

Like every tool on the site, it runs entirely in your browser — nothing you paste is sent anywhere. If you're migrating an MCP server or client right now, it's a quick first pass before you go digging through logs.

Your Custom AI SDK Backend Returns 200 OK and the Chat UI Still Shows Nothing

Bracketly — Thu, 06 Aug 2026 07:37:10 +0000

Your Custom AI SDK Backend Returns 200 OK and the Chat UI Still Shows Nothing

Vercel's AI SDK makes streaming a chat response trivial — as long as your backend is also written in JS and calls streamText().toUIMessageStreamResponse(). The moment you're not in that world — a Go, Python, or Rust backend, a queue that re-serializes the stream, a proxy sitting between your LLM call and the client — you have to hand-produce the exact Server-Sent Events format useChat expects, and there's no error message when you get it wrong. The request succeeds, the status is 200, and the UI just renders an empty message or silently stalls.

I hit this building a small side project and ended up staring at raw response bytes in a terminal for longer than I'd like to admit, so I added an AI SDK Stream Protocol Validator & Debugger to Bracketly.

The protocol itself is a sequence of data: {...} JSON lines, each with a type field — text-start, text-delta, text-end for streamed text; tool-input-start/tool-input-delta/tool-input-available for tool calls; finish and a closing data: [DONE] to end the stream. It reads as simple until you're generating it by hand and discover how many ways there are to get it subtly wrong: a text-delta referencing an id you never opened with text-start, a text-start that never gets a matching text-end, a missing messageId on the initial start event, or just forgetting the trailing [DONE] so the client waits forever for a stream that already finished.

The tool parses each event, checks it against the documented part types and their required fields, and tracks state across the whole stream so it can catch the ordering bugs a plain JSON validator would miss — an orphaned delta, an unclosed span, a tool-output event referencing a toolCallId that was never introduced. It also reconstructs the assembled message text from the deltas, so you can see in one glance what the client would actually have rendered from your stream. Paste the raw response body — straight from curl -N or your browser's network tab — and it runs entirely in your browser tab; nothing gets sent anywhere.

Try it here — feedback and edge cases welcome.

Your Truncated Embedding Vector Is Silently the Wrong Length — Here's the One-Line Fix

Bracketly — Mon, 03 Aug 2026 07:20:00 +0000

Your Truncated Embedding Vector Is Silently the Wrong Length — Here's the One-Line Fix

Most major embedding APIs — OpenAI's text-embedding-3 family, Gemini's gemini-embedding models, Cohere embed-v4, Nomic Embed v1.5 — are now trained with Matryoshka Representation Learning, which means you can safely shorten an embedding after the fact to save storage and search cost, with only a small, predictable accuracy hit. That's a genuinely useful trick. It's also got a one-line gotcha that's easy to miss the first time, so I added an Embedding Vector Truncator & Renormalizer to Bracketly, my free client-side dev tools site.

Here's the gotcha: embeddings from these APIs are L2-normalized to unit length by default — that's what makes cosine similarity and dot-product search interchangeable, and it's part of why the math downstream (nearest-neighbor search, reranking, thresholding) behaves predictably. Slice off the last N dimensions of a unit vector and the result is not unit length anymore — you've changed its magnitude without touching its direction. If you then compare that truncated vector against others with cosine similarity or dot product without renormalizing first, you get numbers that are subtly, silently wrong. Nothing throws an error. Your search results just get quietly worse, and it's the kind of bug that's genuinely hard to notice unless you're specifically looking for it, because the vectors still look like embeddings — same shape, plausible-looking floats.

Providers that expose a native truncation parameter (OpenAI's dimensions argument, for instance) handle this for you automatically. The gap is when you're truncating a vector yourself — a value you already stored at full size and want to shrink for a cheaper index, or a self-hosted Matryoshka-trained model where you're slicing the array by hand. In that case the fix really is one line: take the L2 norm of the truncated slice (square root of the sum of its squared values) and divide every value by it. The tool does exactly that — paste a vector, pick a target dimension, get back the renormalized result plus its norm before and after, so you can confirm it's actually unit length again.

I also added an optional second-vector field so you can paste a comparison vector and see cosine similarity computed two ways: on the original full-length vectors, and on both truncated-and-renormalized. The two numbers won't be identical — you did genuinely discard information, so a small shift is the expected accuracy/size tradeoff Matryoshka truncation is built around — but seeing the actual delta for your own real vectors is a lot more convincing than trusting a blog post's abstract claim that "it should still work reasonably well." Everything runs as plain array arithmetic in your browser tab; nothing you paste is sent anywhere.