Why I Turned RiskyPlugins Into a Hosted MCP Server

I got tired of security tooling living in one tab and AI agents living in another. So I wired RiskyPlugins up as a hosted MCP service with API keys, quotas, audit logs, and billing.

Ali Mosajjal
#mcp#claude-code#codex#ai-agents#browser-extensions#security

Why I Turned RiskyPlugins Into a Hosted MCP Server

I got tired of doing the same stupid dance.

I'd have RiskyPlugins open in one tab, a scorecard in another, a code view in another, then Claude Code or Codex on the side while I copied UUIDs around like it was 2012. That works for a demo. It sucks as a real workflow.

If the whole point of this product is to help people make decisions about risky third-party code, the agent should be able to ask directly. No copy-paste. No "go open this page and summarize it for me." Just ask.

So I finally did the obvious thing and turned RiskyPlugins into a hosted MCP service.

The old way was dumb

Most security products still assume the human is the integration layer.

You search for something. You open a report. You decide which bits matter. Then you manually drag those bits into whatever system you're actually using, a ticket, a Slack thread, an internal chatbot, Claude Code, whatever.

That's wasted motion. Worse, it strips context on the way over. The agent gets a half-baked summary instead of the actual scorecard, history, findings, developer profile, and surrounding metadata.

I don't want RiskyPlugins to be a website you check after the fact. I want it to be infrastructure. If an agent is about to install an extension, review a VS Code setup, compare two plugins, or trace a weird publisher, RiskyPlugins should be callable right there in the flow.

That's what MCP is good at when you don't overcomplicate it.

What I built

The new hosted MCP endpoint gives agents direct access to RiskyPlugins over SSE. Same product, same underlying data, just accessible in the place people are actually working now.

That means:

  • API keys
  • hosted remote MCP transport
  • plan-based quotas
  • premium tool gating
  • usage and audit logging
  • billing hooks for paid plans

I also cleaned up the profile flow so this doesn't feel like a hidden developer feature stapled onto the side of the site.

There's now a dedicated Remote MCP section in profile. You can copy the endpoint, copy the auth header pattern, copy client JSON for Claude Code and Codex, see your quota, see your recent MCP calls, and see which tools are premium-gated. That's how it should have looked from day one.

Why this matters

Browser extensions, IDE plugins, MCP servers, agent skills, half of this ecosystem is third-party code with broad permissions and almost no review.

People keep pretending these are separate problems. They aren't.

A Chrome extension that reads cookies is one flavor of supply chain risk. A VS Code extension that shells out and phones home is another. A remote MCP server with access to sensitive project context is the same class of problem wearing different clothes.

The useful question isn't "is this a browser extension?" or "is this an AI tool?"

The useful question is: what code am I trusting, what can it touch, who published it, what changed, and how much confidence do I have that it won't do something disgusting later?

RiskyPlugins already had most of the raw ingredients for that. Search. scorecards. findings. historical views. developer clustering. artifact inspection. What it didn't have was a clean way for agents to consume that directly.

Now it does.

The product angle is pretty simple

I'm not interested in pretending MCP itself is the business.

MCP is the pipe.

The business is risk intelligence for third-party code that people install without thinking. Hosted MCP just happens to be the fastest way to get that intelligence into the workflows that matter now.

Free users can connect and use conservative limits. Paid users get more keys, more quota, longer audit retention, and premium tools. Enterprise users will want the obvious things: private deployments, isolated access, better policy controls, more retention, and fewer surprises.

That's not complicated. It's just useful.

I also don't want this turning into fake agent security theater

A lot of AI security products right now are basically wrappers around vibes.

They'll happily tell you they are "AI-native" and "agentic" and "redefining trust" or whatever. Then you look under the hood and it's a generic prompt, a dashboard, and a lot of soft language covering the fact that nobody knows what the tool actually saw or why it made the decision it did.

I'm not building that.

The MCP layer sits on top of actual analysis work:

  • static scanning
  • finding normalization
  • risk scoring
  • historical context
  • publisher correlation
  • artifact access

The agent isn't getting magic. It's getting structured access to data that already exists and can be inspected.

That's important. If the answer is "this thing looks bad," I want the next question to be "why?" and I want there to be a real answer.

The bigger picture

I think agent-facing security products are going to split into two camps.

One camp will build toys that sound smart in demos.

The other will build boring infrastructure that agents can rely on. Clear inputs. Clear outputs. Real permissions. Real audit trails. Real product boundaries.

I want RiskyPlugins in the second camp.

The hosted MCP work is one step in that direction. It moves the product out of the browser-only bucket and into the place where people are actually making decisions now, inside Claude Code, Codex, and whatever comes next.

And honestly, this was overdue.

If I'm asking an agent to touch my repo, my shell, my editor, or my cloud account, I also want that agent to be able to ask a decent risk-intelligence system whether the plugin, extension, or MCP server in front of it looks sane.

Now it can.