- The problem
- Creators wanted to use HYVIRAL from the AI assistant they already have, such as Claude. Opening that door risked a second, looser version of the product: different prices, skipped permissions, tools running for free.
- What I did
- I made the outside assistant another way into the same tool system. It decides what to do; HYVIRAL does the work, checks permissions and charges for it. For sign-in, I tested a ready-made provider against a rule written in advance, and built the piece it failed.
- What happened
- Outside assistants get the same 82 tools at the same prices as the app. The provider test failed on permissions, so HYVIRAL runs its own sign-in server.
I chose to let the outside assistant do the planning while HYVIRAL does the work, and I wrote the pass-or-fail rule for the provider test before it ran.
I wanted people to use HYVIRAL from the assistant they already work with, so I made MCP, the open standard that lets AI assistants use outside tools, another way into HYVIRAL’s tool system. The connecting assistant plans the work; HYVIRAL runs each step, checks what the assistant is allowed to do and charges for paid work in credits, HYVIRAL’s prepaid units. The risk was a second copy of the product that skipped those controls or let its prices drift. That entry point later became the product; the decision has its own page.
Connecting an agent
Plan within the product.
Plans its own workflow.
Signed in · explicit list of toolsThe MCP bridge adds sign-in and usage accounting around the existing tools.
Offer the tools. Let the outside assistant combine them.
Share the machinery, let the outside assistant plan
Calls from an outside assistant go through HYVIRAL’s tool registry, the one place where every tool runs, and nowhere else. The transport is the official TypeScript MCP SDK with a NestJS adapter and Streamable HTTP, and each call ends in the same ToolRegistryService.execute() the app uses. The app and the MCP path share per-tool prices, one credit balance per account and the same background-job system, and a tool needs an explicit entry in the MCP catalogue, with a permission scope and an execution contract, before an outside assistant can call it.
The outside assistant receives individual tools and decides how to combine them. Routing its calls through HYVIRAL’s own manager and specialist agents would have planned the work twice.
The tradeoff is integration work. The MCP path skips the app runtime that normally records provider usage and settles charges, so the bridge has to restore that accounting itself, alongside sign-in and the price confirmation. That cost buys reuse of the product’s tools and jobs without forcing its planning layer on every client.
The rule that calls from outside assistants go only through the tool registry, the bridge code that follows it, and the usage accounting the bridge has to restore.
Read the sourceLet one required feature decide build versus buy
Sign-in for outside assistants had to express what a connected assistant may do: HYVIRAL’s own permission scopes, a branded consent screen, client registration and discovery metadata, with tokens tied to the intended service. I set the rule before the experiment: if any mandatory requirement failed, HYVIRAL would run its own authorization server.
On 21 August 2026 I tested Supabase’s authorization server (CLI 2.115.0 with GoTrue v2.187.0). Discovery metadata and client registration passed. A request for HYVIRAL’s intel:read permission came back unsupported scope, which alone triggered the rule; token binding was never proven either way.
Running sign-in in-house keeps the permission vocabulary and the consent flow under my control, and makes its endpoints, token handling and protocol review my responsibility. The rule settled build versus buy for the versions tested; the security of the resulting server is a separate obligation.
The pass-or-fail rule written before the sign-in provider test, the results table, and the response that ruled the provider out: unsupported scope intel:read.
Read the sourceResults
The bridge enforces the boundary in code: it builds a signed-in session, calls only the tool registry, and restores the usage accounting the app would otherwise do. Without that last step, every AI-backed read tool would have run at zero credits.
The provider test recorded discovery metadata PASS, client registration PASS and custom permission scopes FAIL. The rule written in advance chose the in-house path with no further discussion.
GET /auth/v1/oauth/authorize?…&scope=intel%3Aread→ 302 …/callback?error=invalid_request&error_description=unsupported+scope%3A+intel%3Aread