feat(registry): accept chittyregister service binding on POST /v0.1/servers#112
feat(registry): accept chittyregister service binding on POST /v0.1/servers#112chitcommit wants to merge 1 commit into
Conversation
…ervers Make the register→discovery bridge possible. The global write gateway already honors the X-Chitty-Internal-Binding: chittyregister bypass for non-GET requests, but the inner handler for POST /v0.1/servers re-gated on MCP_REGISTRY_ADMIN_TOKEN (Bearer) only — so a service-binding call from ChittyRegister (which carries no Bearer) was rejected, making the canonical first-party write path structurally impossible. Align the inner check with the gateway's isServiceBinding test; the admin token still works for out-of-band operator writes. This is the surface MCP clients + the mcp.chitty.cc portal projection read (mcp-servers: KV via GET /v0.1/servers), and it is what makes the locked CQRS model (Register = write, Registry = discovery) true for MCP servers. Foundation write-path change — requires operator/canon review before deploy. Tests (jest): binding-bypass accepted with no admin token, lands in KV, exact hostname survives formatMcpRegistryEntry round-trip, same-version upsert, non-binding-no-token still 401. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
chittyregistry | 5eedf18 | Jun 12 2026, 06:30 AM |
|
@coderabbitai review |
|
Warning Review limit reached
More reviews will be available in 48 minutes and 35 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Companion to chittyfoundation/chittyregister#register-to-mcp-discovery-bridge
Foundation write-path change — DO NOT MERGE without operator/canon review.
Why
POST /v0.1/serversis the MCP discovery surface that MCP clients and themcp.chitty.ccportal projection read (mcp-servers:KV). The global write gateway already honors theX-Chitty-Internal-Binding: chittyregisterservice-binding bypass for all non-GET writes, but the inner handler forPOST /v0.1/serversre-gated onMCP_REGISTRY_ADMIN_TOKEN(Bearer) only. A service-binding call from ChittyRegister carries no Bearer, so the canonical first-party writer was rejected — making the register→discovery bridge structurally impossible and leaving the CQRS model (Register = write, Registry = discovery) untrue for MCP servers.Change
Align the inner check with the gateway's
isServiceBindingtest (!CF-Connecting-IP && X-Chitty-Internal-Binding: chittyregister). The admin token still works for out-of-band operator writes; the binding is the canonical first-party path. No new secret.Tests (jest, 4 new; full suite 46 green)
mcp-servers:KV undername:versionformatMcpRegistryEntryround-trip viaGET /v0.1/servers401(regression guard)🤖 Generated with Claude Code