Skip to content

docs: correct the Zapier mcp-registry partition counts (58, not 60) - #39

Closed
hamchowderr wants to merge 1 commit into
mainfrom
claude/cli-sdk-zapier-oauth-2k1zob
Closed

hamchowderr wants to merge 1 commit into
mainfrom
claude/cli-sdk-zapier-oauth-2k1zob

Conversation

@hamchowderr

Copy link
Copy Markdown
Owner

What

Corrects one line in CLAUDE.md. The Zapier SDK classification protocol claimed the three sets partition the mcp registry as 10 + 27 + 23 = 60. The real numbers are 10 + 25 + 23 = 58.

Why

READ_ONLY holds 25 methods, not 27. The 27 figure counted two string literals from the getActionRun comment (status: "waiting" / status: "error") as if they were method names.

The number matters because it is the documented checklist item after every SDK bump — "confirm the registry-method count still equals the sum of the three sets." Anyone following it against a real registry would find 58, not 60, and reasonably conclude two methods had gone missing.

How it was verified

Enumerated sdk.getRegistry({ package: "mcp" }) in a clean scratch install at both 0.103.0 (the pinned version) and 0.111.1 (latest), then diffed each name list against the three sets parsed out of zapier-sdk-tools.ts with comments stripped:

  • Registry returns 58 methods at both versions.
  • The two registries are identical — no additions, no removals.
  • Unclassified: none. Stale (classified but absent from the registry): none.

So the partition is exact; only the documented count was wrong. This also means the pending 0.103.0 → 0.111.1 bump needs no reclassification work — everything added across those 15 releases (VFS, agentic management, runWorkflowDraft) landed on the experimental client, which is outside the mcp registry.

Risk

Documentation only. No code, no test, no behavior change. tests/unit/zapier-sdk-tools.test.ts already asserts the invariant correctly and was never keyed to the printed number.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PVrtz6XV3M8zxBttQUYKBz


Generated by Claude Code

READ_ONLY holds 25 methods, not 27 — the previous figure counted the
strings "waiting" and "error" from the getActionRun comment. The registry
itself returns 58 methods, and is byte-identical at 0.103.0 and 0.111.1,
so the pending SDK bump needs no reclassification.

Verified by enumerating sdk.getRegistry({ package: "mcp" }) at both
versions and diffing against the three classification sets.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PVrtz6XV3M8zxBttQUYKBz
@vercel

vercel Bot commented Sep 14, 2026

Copy link
Copy Markdown

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

Project Deployment Actions Updated
foreman Ready Ready Preview Sep 14, 2026 8:59am UTC

@supabase

supabase Bot commented Sep 14, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project ihhdqzljgdnatuwzrlfm because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant