I gave the team one instruction this morning: make our site speak the protocol before anyone else does. Not because we needed the functionality — our site works fine for humans. Because the credibility of telling customers "you should implement WebMCP" goes up by a factor of ten when you can point to your own URL and say "we already did."
Here's what we shipped. Six tools registered through navigator.modelContext.registerTool(), the imperative JavaScript API that Chrome exposes when the WebMCP flag is enabled:
get_services — Returns our three engagement tiers, pricing model, and team size. An agent researching AI consulting firms gets structured data instead of parsing our Engagement page.
get_team — Returns the full 25-person roster with roles, categories, and specialties. Filterable by category. An agent asking "who handles competitive intelligence?" gets SCOPE's name and role in JSON, not a screenshot of our Agents page.
search_insights — Full-text search across 510 Signal posts. Returns titles, excerpts, dates, and URLs. An agent researching what we think about sales automation gets a curated result set that links back to the site.
get_insight — Fetch a single post by slug with an extended excerpt. The natural follow-up after search finds something interesting.
submit_inquiry — Structured lead capture. Name, company, email, use case, preferred contact method. The agent fills in the fields, we get a qualified inquiry in our CRM. No chat required.
get_case_studies — Five capability-focused engagement examples covering agent deployment, workflow automation, architecture advisory, sales pipeline, and document processing.
Six for six. Every tool a visiting agent would need to evaluate us as a vendor and start a conversation.
Why same-day matters
The post I published this morning was analysis. This is proof of work. The gap between "that's a good idea" and "here's the commit hash" is where credibility lives. Twenty years in enterprise tech sales taught me that the vendor who shows the working demo beats the vendor who shows the roadmap slide. Every time.
ROCKY built the tool definitions. FLUX would have handled the worker deployment, but the /inquiry endpoint was straightforward enough that the build pipeline handled it without intervention. The whole thing — type declarations, static data, post index generation, worker endpoint, six tool definitions, registration logic, tests, build verification — shipped in three hours. I walked my eight-year-old to school for forty-five minutes in the middle of it. The agents kept building while I was gone.
The engineering is deliberately simple. Static tools return hardcoded data. Search tools fetch a build-time JSON index. The inquiry tool hits our existing Cloudflare Worker. Feature detection means zero cost when WebMCP isn't available — if (!navigator.modelContext) return and the code never loads. No polyfill. No runtime overhead. No impact on human visitors.
What I'm telling customers now
This morning I told customers to audit their web interfaces. Tonight I'm adding a fourth point to that list: build one tool this week. Not six. One. Pick the highest-value read operation on your site — the thing your customers' agents will ask first — and register it. The Chrome flag is live. The Model Context Tool Inspector extension is in the Chrome Web Store. You can verify it works in ten minutes.
The spec will evolve. The implementations will mature. But the companies that ship WebMCP tools in 2026 will be the ones whose products AI agents actually know how to use in 2027.
We shipped ours today. Your move.
Transmission timestamp: 07:51:32 AM