perf(tools): read tool metadata instead of the registry on client paths

[waleedlatif1]

Stacked on #6153 → #6152 → #6151. Bases retarget as each merges.

This is the payoff PR. It cuts the last four edges pulling @/tools/registry into the workspace shell.

Module graph — every workspace route, not just the canvas

route	before	after
/w (canvas)	6,592	1,908	−71%
/logs	6,227	1,543	−75%
/tables	5,903	1,217	−79%
/files	5,996	1,310	−78%
workspace layout	5,751	1,063	−82%

@/tools/registry is now unreachable from all of them.

Dev cold compile (canvas, n=3, cache cleared between runs)

	compile	dev-server RSS
before	32.3s / 31.4s / 30.1s	9.0–12.5 GB
after	22.4s / 22.2s / 21.6s	7.8–9.2 GB

That lands almost exactly where the dev:minimal escape hatch measured (20.0s / 6.7 GB) — but without its downside. dev:minimal swaps in curated registries that drop ~250 services; this keeps every tool working.

What was rewired

edge	now reads	needed
lib/workflows/blocks/block-outputs	getToolOutputsMetadata	outputs
serializer/index	getToolParams	params
lib/workflows/sanitization/validation	hasToolId	existence only
tools/params	getToolMetadata	params, oauth, name

tools/params.ts was the stubborn one. mcp-dynamic-args.tsx imports only formatParameterLabel from it — so the entire registry rode in behind a string-formatting helper, the same shape as the mergeToolParameters edge in #6152.

Behaviour preservation — the actual risk

getTool resolves an unversioned name onto its newest version (notion_search → notion_search_v2). A plain key lookup would have silently reported 246 versioned tools as missing — a quiet correctness bug, not a crash.

So resolveToolId is reproduced against the id set and differentially tested: 4,404 probes (every registered id, every stripped base name, and an unknown) comparing old vs new resolution and existence — 0 mismatches.

Adds a third generated artifact, tool-ids.ts (~110 KB). Resolution needs only the key set, so @/tools/metadata and @/tools/metadata-outputs both resolve through it and stay independent of each other — and an existence check costs ~110 KB instead of ~4 MB.

ToolWithParameters.toolConfig and SubBlocksForToolInput.toolConfig narrow from ToolConfig to ToolMetadata. The only external reader is tool-input.tsx, which uses .name.

Test plan

• vitest run tools/ serializer/ lib/workflows/ providers/ executor/ app/ — 8,953 passed
• Differential resolution parity: 4,404 probes, 0 mismatches
• New version-resolution tests, deliberately selecting a versioned tool whose base name is not registered (the 209 tools where both exist don't exercise resolution at all)
• tsc --noEmit clean
• tool-metadata:check in sync
• biome clean

One pre-existing failure, cloud-review-tools.test.ts, is environmental (shells out to a rg binary not installed locally); verified identical on base.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 1, 2026 6:08pm

[cursor]

PR Summary

Medium Risk
Broad rewiring of tool lookup across serialization, validation, and UI with version-resolution parity relied on tests rather than runtime fallbacks; incorrect resolution would mis-validate workflows or show wrong tool metadata without crashing.

Overview
This PR finishes cutting @/tools/registry out of workspace client graphs by routing metadata-only callers to generated artifacts instead of getTool.

A new @/tools/tool-ids module (~110 KB) exposes hasToolId, resolveToolId, and getToolIds. resolveToolId mirrors getTool’s unversioned→latest-version behavior so versioned tools are not silently treated as missing. @/tools/metadata and @/tools/metadata-outputs now resolve ids through tool-ids instead of duplicating id lists.

Call sites switch off the registry: block output inference uses getToolOutputsMetadata; serializer validation uses getToolParams; workflow tool validation uses hasToolId; tools/params and access-control UI use getToolMetadata; ToolWithParameters / tool-input types narrow to ToolMetadata.

The metadata sync script emits tool-ids.ts as a third generated file. Tests add toolsMetadataMock and serializer tests mock @/tools/metadata where params/name matter; docs/skills describe the three-tier import table and mock guidance.

^{Reviewed by Cursor Bugbot for commit 7e38861. Configure here.}

[greptile-apps]

Greptile Summary

This PR removes the remaining workspace-client dependencies on the executable tool registry by routing existence, parameter, and output lookups through generated metadata while preserving version resolution.

• Adds a compact generated tool-ID artifact and registry-compatible ID resolver.
• Migrates workflow validation, output discovery, serialization validation, and tool parameter UI helpers to metadata-only APIs.
• Extends generation and tests to cover artifact synchronization, unknown IDs, and unversioned-to-latest resolution parity.

Confidence Score: 5/5

The PR appears safe to merge; no concrete changed-code failure remains after checking resolver parity and the contracts of migrated consumers.

The metadata APIs preserve direct-ID and latest-version resolution, generated data includes every field used by the migrated paths, and custom or MCP behavior remains unchanged.

Important Files Changed

Filename	Overview
apps/sim/tools/tool-ids.ts	Adds static ID lookup and unversioned-to-latest resolution matching the executable registry’s existing semantics.
scripts/sync-tool-metadata.ts	Extends metadata generation and check mode to produce and verify the generated tool-ID artifact.
apps/sim/tools/metadata.ts	Routes metadata and parameter lookup through version-aware ID resolution.
apps/sim/tools/metadata-outputs.ts	Adds version-aware output metadata lookup without importing executable tool definitions.
apps/sim/tools/params.ts	Replaces full registry lookups with sufficient serializable metadata for current parameter UI consumers.
apps/sim/serializer/index.ts	Validates user-only required parameters from generated parameter metadata while preserving existing behavior.
apps/sim/lib/workflows/sanitization/validation.ts	Uses the generated ID set for built-in tool existence validation while retaining custom and MCP exemptions.
apps/sim/lib/workflows/blocks/block-outputs.ts	Reads generated output definitions instead of loading full executable tool configurations.
apps/sim/tools/metadata.test.ts	Adds coverage for unknown IDs and registry-compatible version resolution across metadata artifacts.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Registry[Executable tool registry] --> Generator[sync-tool-metadata]
  Generator --> IDs[Generated tool IDs]
  Generator --> Metadata[Generated params / OAuth metadata]
  Generator --> Outputs[Generated output metadata]
  IDs --> Validation[Workflow tool validation]
  IDs --> Resolver[Version-compatible ID resolver]
  Resolver --> Metadata
  Resolver --> Outputs
  Metadata --> Serializer[Serializer field validation]
  Metadata --> ParamsUI[Tool parameter UI helpers]
  Outputs --> BlockOutputs[Block output discovery]

Loading

_{Reviews (1): Last reviewed commit: "perf(tools): read tool metadata instead ..." | Re-trigger Greptile}

[waleedlatif1]

Production bundle — the open question is now settled

I flagged in the scoping that it was unknown whether prod tree-shaking already removed the registry, which would have made this a dev/CI-only win. It doesn't.

Full next build on staging vs this stack, same machine:

client JS (.next/static/chunks)	before	after
raw	111.65 MB	103.80 MB	−7.85 MB
gzipped	26.09 MB	23.68 MB	−2.41 MB (−9.2%)

That is a net reduction — it already absorbs the ~8 MB of generated metadata artifacts this stack adds. The registry's executable config was genuinely shipping to browsers.

So the win is three-fold, not one:

	before	after
canvas module graph	6,592	1,908 (−71%)
dev cold compile	30.1–32.3s	21.6–22.4s
dev restart (with #6151)	30.1–31.9s	4.3–4.4s
dev-server RSS	9.0–12.5 GB	~4.0 GB
prod client JS (gzip)	26.09 MB	23.68 MB (−9.2%)

[waleedlatif1]

Behaviour-neutrality evidence

Since this swaps the data source under four call sites, "tests pass" felt insufficient. Differentially compared the old registry reads against the new metadata reads for every tool, on the real registry:

probes: 4404   (every tool id, every stripped base name, and an unknown)
  resolve mismatches  : 0
  existence mismatches: 0
  params mismatches   : 0
  outputs mismatches  : 0
  name mismatches     : 0

Those five dimensions are exactly what the rewired call sites read: block-outputs → outputs, serializer → params, validation → existence, tools/params → params/name, all via resolution.

Plus:

• Full suite: 17,277 passed (vitest run, whole app). The single failure is cloud-review-tools.test.ts, which shells out to a rg binary not installed on my machine — CI installs ripgrep, and it fails identically on the base commit with these changes stashed.
• tsc --noEmit clean, 12.0s (baseline 12.6s).
• HTTP smoke on a real workspace against a running dev server — /w, /logs, /tables, /files and /api/workflows all 200, no server-side errors.

I did attempt an in-browser click-through of the tool-input panel as well; the Chrome extension wasn't responding, so that specific check is not done. The differential above covers the same code paths at the data level, but flagging it rather than implying otherwise.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 7e38861. Configure here.}