SkyRingAI-WebMCP

Inspiration

Small-business owners using an AI receptionist accumulate valuable context across call analytics, transcripts, appointments, and assistant settings. Answering a question like “Which qualified callers need follow-up?” normally means navigating several screens and then switching to another workflow to act on the answer. Conventional browser agents must guess at controls and page state, which is brittle and especially risky when changing a live voice assistant.

What it does

SkyRingAI-WebMCP turns the authenticated SkyRingAI customer portal into a structured, agent-operable workspace. After the existing Supabase session resolves an active customer, the portal registers seven private WebMCP tools:

get_dashboard_summary
search_call_history
get_call_details
list_upcoming_appts
get_assistant_config
preview_assistant_update
publish_assistant_update

A customer can ask ChatGPT to summarize performance, find qualified calls, inspect a bounded transcript, list upcoming appointments, read the full receptionist configuration, and propose changes. Configuration changes use an explicit preview-before-publish workflow: the preview returns field-level differences and a short-lived ID; only a separate publish request saves the reviewed change.

The production demo uses a dedicated non-admin judge account with isolated fictional records, a disposable VAPI assistant, and a live inbound demo number. The public repository contains the complete WebMCP contracts, seven-tool implementation, registration lifecycle, fixture provider, tests, and runnable sanitized demo—not the private commercial SaaS.

Why WebMCP

WebMCP is a strong fit because the useful unit is a trusted business operation, not a page click. An agent receives bounded tools with explicit schemas, read/write annotations, and authentication-derived scope instead of guessing how to traverse a dashboard.

This lets a person and agent combine analytics, call discovery, transcript review, appointment context, and controlled action in one conversation. Tool inputs cannot select a customer or tenant. Stored transcript and database text is treated as untrusted, phone output is masked, and ranges, transcript size, pagination, and configuration fields are bounded.

How we built it

The tool layer is organized around a provider interface. The portal resolves the authenticated Supabase user and active customer, constructs a provider bound to that trusted context, validates tool inputs, repeats customer filters on production reads, and normalizes privacy-bounded results. An abortable lifecycle removes every private tool when the authenticated session ends.

Assistant updates first read the complete current configuration so list replacements can preserve stable IDs. Greeting-only changes use the existing direct assistant path. Every effective non-greeting change must complete the authenticated N8N preview workflow before a publishable ID exists. Publishing accepts only that short-lived preview ID, and the server resolves the customer again before saving and requesting the downstream VAPI update.

Challenge-period enhancement

SkyRingAI existed before this challenge and briefly experimented with one small public, read-only WebMCP pricing tool plus declarative form annotations. During the submission period I built a substantial new authenticated customer-portal capability with Codex: seven tools spanning dashboard analytics, call search, bounded transcripts, appointments, complete assistant configuration, and preview-before-publish updates. I added the customer-scoped production provider, validation and privacy boundaries, lifecycle cleanup, controlled N8N mutation path, automated tests, dedicated production judge tenant, and separate open-source challenge repository. This expands the early experiment into a coherent, working business operations workflow.

How I used AI and Codex

ChatGPT is the runtime conversational control surface. VAPI powers the voice receptionist, and N8N powers the existing non-greeting configuration generation and update workflow.

Codex was the primary engineering collaborator for architecture inspection, scoping, implementation, debugging, tests, security hardening, production verification, and open-source packaging. Lovable helped provision and verify the isolated production judge tenant through its connected Supabase and existing server integrations. The feature was tested live through ChatGPT from another machine.

Accomplishments

Seven authenticated WebMCP tools working in production.
Customer identity derived from the trusted session, never a tool argument.
Bounded outputs, masked phones, safe errors, strict schemas, and untrusted-content hints.
Human-reviewable, single-use preview-before-publish assistant mutations.
Real N8N preview/publish integration for non-greeting changes.
Verified RLS isolation and a dedicated fictional judge environment.
Runnable fixture-only open-source edition with no production credentials or customer data.
Passing automated tests and production build.

What I learned

The most important lesson was that exposing more tools is not automatically better. Agent-native product design is about creating trustworthy operational boundaries: give the agent enough structured context to be useful, keep identity outside caller-controlled input, label untrusted data, constrain outputs, and separate “show me what would change” from “make the change.”

What's next

After the challenge, I plan to expand customer-controlled WebMCP workflows while keeping the same authentication, tenant, privacy, and preview-before-publish model. Likely next areas include controlled follow-up actions, broader analytics questions, and additional assistant lifecycle operations.