DEV Community: Opula

Your GitHub repo can be a Claude plugin marketplace. Here is the whole setup.

Opula — Wed, 29 Jul 2026 10:46:43 +0000

I spent an afternoon turning a GitHub repo into a Claude plugin marketplace.
The docs get you 80% there. The last 20% is where I burned two hours, so
here's the setup plus the two gotchas that aren't written down anywhere.

The structure

Two files matter:

.claude-plugin/marketplace.json   <- the catalog
plugins/opula/plugin.json         <- one entry per plugin

marketplace.json lists what's in the repo. Each plugin points to its own
plugin.json, which declares name, version, and (if it ships an MCP server)
an .mcp.json pointing at a remote HTTP endpoint. Mine authenticates via
Dynamic Client Registration, so there's no API key to hand out. Anyone who
installs it goes through OAuth on first connect.

Installing it

Two lines, from inside Claude Code:

/plugin marketplace add evan-moon/opula-plugin
/plugin install opula@opula

That's it. No forking, no local clone.

Gotcha 1: two version numbers, one sync you can't see

plugin.json and marketplace.json both carry a version. Bump one and
forget the other, and Claude Code will happily install the stale one with no
error. Worse: claude.ai's marketplace sync is manual on top of that, so a
fix you shipped an hour ago might not reach anyone who installs through the
web client until you go trigger the sync yourself. Claude Code gives you
zero visibility into this step. You just have to remember it exists.

Gotcha 2: installed but "broken"

If someone installs the plugin but never connects the underlying MCP
server, they'll see the skills load fine and then hit a wall the moment a
skill tries to call a tool. Nothing crashes, nothing errors clearly, it just
looks broken. The fix is a connection step, not a bug fix, but nothing in
the UI tells you that's what's missing. If you're shipping a plugin with an
MCP backend, put the "go connect it" instruction directly in your first
skill's output, not just in the README.

What the skills are actually doing

Worth saying out loud: the 6 skills in this plugin aren't a smarter model
bolted on top. They're routing. analyze-holding walks a fixed catalog of
checks instead of freestyling an analysis. month-end asks a clarifying
question up front if data's missing instead of guessing. import-ledger
confirms the column mapping before it writes anything. None of that is
"AI reasoning" in any interesting sense, it's just structure that keeps the
model from improvising in places where improvising is the wrong move.

Token cost, since nobody publishes this

Rough numbers, not exact: always-on context from the plugin lands around
1k tokens, every turn, whether you use it or not. Per-skill invocation adds
roughly 1.5k-2k depending on which one fires and how much markdown/code
gets pulled in. I'm rounding these on purpose, if you're building one of
these, run /context in a session with the plugin installed and get your
own real numbers rather than trusting mine.

This is the plugin for opula,
a portfolio copilot I built for tracking holdings across multiple brokers.
The plugin adds 6 skills on top of the existing MCP connector; same account,
Pro plan or above. If you hit either gotcha above while setting up your own
marketplace, I'd genuinely like to hear about it.

Can Claude Analyze My Portfolio?

Opula — Tue, 14 Jul 2026 21:17:06 +0000

If Claude can already search the web, read a 10-K, and explain what a rate cut does to long-duration equities, the fair question is why you would connect anything to it at all. It is the right question, and the honest answer is that for a large class of questions you should not. Raw Claude is enough.

The gap is narrower and sharper than "Claude does not know finance." Claude knows finance. What it does not know is you.

What raw Claude already does well

Be clear about this before the sales pitch, because pretending otherwise would insult anyone who has actually used it.

Claude with web search will look up a current quote, summarize an earnings call, explain a valuation multiple, walk you through how a Monte Carlo simulation works, and reason about a macro scenario better than most of the commentary you would read instead. If your question is about the world, and not about your own balance sheet, a connector adds nothing. Ask Claude directly.

The trouble starts the moment the answer depends on what you actually own.

Four things that break when the question is about your money

1. It starts from zero every time

A chat has no memory of your holdings. You can paste them in, and many people do, and it works for exactly one conversation. There is no cost basis, no purchase date, no daily snapshot series behind it. So "how concentrated am I really", "what is my realized gain this year", and "how correlated are my top five positions over the last 90 days" are not questions it can answer. It can only answer them about the numbers you re-typed, this once, from memory.

2. The same question gives a different answer twice

LLM inference is not deterministic, and it is not deterministic even at temperature zero. Thinking Machines Lab traced the cause to batch-invariance in inference kernels: the batch your request lands in varies with server load, so the arithmetic varies with it. They fixed it in a research setting and got 1,000 bitwise-identical runs, which tells you how much engineering it takes to get the property most people assume is free.

For an essay, drift between two runs is invisible. For "what percent of my net worth is in one stock", it is the whole point. A number you cannot reproduce is not a number, it is an opinion with decimals.

3. It estimates where it should compute

Ask a model for a Sharpe ratio and it will give you one. Whether it computed it or produced a plausible-looking float is not visible from the output. Research on financial-domain LLMs finds they frequently get figures wrong when they are not grounded in a database, and that grounding cuts financial hallucination substantially.

This is not a reason to distrust Claude. It is a reason not to ask it to be a calculator. Judgment is what a model is good at. Arithmetic over your own ledger is what a rule should do.

4. It cannot see the assets that are not on the web

Web search finds what is published. Your jeonse deposit is not published. Neither is the gold bar you bought at a Korean bank, the apartment you paid off, or the stake you hold in a private company. No amount of searching surfaces them, because they are not missing from the internet, they are simply not on it. For many people these are the largest line items they own, and any analysis that silently excludes them is not conservative, it is wrong.

The split

Your question	Raw Claude	With a connector
"What does a hawkish Fed do to growth stocks?"	Good answer. Use it.	No benefit
"Explain how a Monte Carlo projection works"	Good answer. Use it.	No benefit
"How concentrated is my portfolio right now?"	Cannot know	Computed from your holdings
"What is my realized gain this year?"	Cannot know	Computed from your transactions
"If equities drop 15%, what happens to me?"	Guesses a number	Point estimate per holding, via beta
"When do I hit my FIRE number, and how wide is the range?"	Estimates, differently each ask	Monte Carlo over stated assumptions
"Include my jeonse deposit and physical gold"	Invisible	Tracked as real assets

What Opula actually adds

Not intelligence. Claude already has that, and Opula does not try to replace the reasoning with a rule.

Opula gives Claude two things it cannot get on its own: a durable memory of what you own, in one currency, with cost basis and history, and a set of deterministic tools that compute over it. Concentration, correlation, drawdown, savings rate, net-worth attribution, and forward projections come back as rule-computed data, the same numbers on the second ask as on the first. Claude then does what it is good at, which is reading those numbers with you and arguing about what they mean.

The division of labor is deliberate: Opula returns data, not narrative, and never tells you what to buy. It is diagnostic data and education, not licensed advice. What to do about it stays between you and Claude, and for anything with a tax or legal edge, your local professional.

FAQ

Can Claude analyze my portfolio without a connector? It can analyze holdings you paste into the chat, for that one conversation. It has no memory of them afterward, no cost basis, and no price history, so anything requiring your past (realized gain, drawdown, correlation over time) is out of reach.

Why do I get different numbers when I ask Claude the same question twice? LLM inference is nondeterministic in practice, even at temperature zero, largely because the server batch your request joins varies. That is fine for prose and not fine for a percentage of your net worth.

Is a connector just a way to feed Claude my data? Feeding it data is half. The other half is that the computation happens outside the model, by rule, so the number cannot drift or be estimated into existence.

Do I still need Claude if I use Opula? Yes, and that is the design. Opula has no opinions and writes no narrative. It returns facts about your money; Claude is what makes sense of them.

If you want to try the connector side of this, I am building Opula, a hosted MCP server that gives Claude a durable, computed view of your own money.

Sources

What building a remote MCP server taught me about authentication

Opula — Mon, 13 Jul 2026 18:11:05 +0000

When I started building Opula - a hosted MCP server that lets Claude read your portfolio, net worth, and cash flow so you can just ask about your own money - I assumed the hard part would be the finance logic. It wasn't. The hard part was authentication.

MCP moves fast, the auth story changed twice in 2025, and most of the "add auth to your MCP server" tutorials online are already out of date. So here is the mental model I wish I'd had on day one: how transports shape your auth options, what the current spec actually requires, and the standards (and anti-patterns) that matter in production.

First: auth depends entirely on your transport

MCP defines two standard transports, and they live in completely different security worlds.

	STDIO	Streamable HTTP
Deployment	Local subprocess	Remote network service
Clients	1:1 with the host	N clients, multi-user
Network exposure	None	Yes
Auth model	OS process isolation, env vars	OAuth 2.1, bearer tokens, API keys, mTLS
Cross-machine	No	Yes

(SSE was a third, earlier transport. It's deprecated now - if you're starting today, don't.)

The takeaway: if your server runs locally over STDIO, you mostly don't need auth. The client already trusts the process it spawned, and you pass secrets via environment variables. The official guidance is explicit about this: for STDIO, use environment-based credentials instead of OAuth.

The moment you go remote over Streamable HTTP - which is what any hosted/SaaS MCP server is - the picture flips. Now you have a single HTTP endpoint (say POST /api/mcp) reachable over the network, potentially by many users, and you own the entire authentication and authorization story.

Opula is remote by nature (your Claude talks to https://opula.io/api/mcp), so everything below is about the HTTP side.

The spec you should actually read: 2025-06-18

The MCP authorization spec was revised in June 2025, and this revision is the one to build against. The single most important sentence in it:

A protected MCP server acts as an OAuth 2.1 resource server.

That one line reframes the whole problem. Your MCP server is not an identity provider. It doesn't own login screens or issue tokens. It validates tokens that some authorization server issued, and it serves protected resources (your tools) when the token checks out.

The June revision made two changes worth knowing if you read older tutorials:

It cleanly separated the resource server (your MCP server) from the authorization server. You're encouraged to delegate token issuance to a dedicated auth server rather than bolt an OAuth provider onto your tool server.
It removed the old fallback default endpoints (/authorize, /token, /register) in favor of mandatory metadata discovery via RFC 9728.

The standards stack

Modern MCP auth is basically four OAuth RFCs wearing a trench coat. Here's the whole cast:

RFC	Role	What it does
RFC 9728	Resource Server	Protected Resource Metadata - your server advertises which auth servers to trust
RFC 8414	Authorization Server	AS Metadata - the auth server advertises its endpoints
RFC 7591	Client	Dynamic Client Registration - clients register themselves without manual setup
RFC 8707	Token audience	Resource Indicators - tokens are bound to a specific target resource

Plus OAuth 2.1 Authorization Code + PKCE as the grant flow. Let's walk the flow the way a client actually experiences it.

The discovery flow, step by step

1. Client hits your endpoint with no token. You reject it with a 401 - but not a bare 401. You include a WWW-Authenticate header pointing at your metadata:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://opula.io/.well-known/oauth-protected-resource"

2. Client fetches your Protected Resource Metadata (RFC 9728). This is a tiny JSON document at a well-known URL that says "here's who I am and who issues tokens for me":

{
  "resource": "https://opula.io/api/mcp",
  "authorization_servers": ["https://auth.opula.io"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["mcp:tools:read", "mcp:portfolio:read"]
}

This is the piece that older guides skip and the June spec makes mandatory. The client no longer guesses your auth endpoints - you tell it.

3. Client discovers the authorization server (RFC 8414), optionally registers itself (RFC 7591), and runs a standard OAuth 2.1 Authorization Code flow with PKCE. PKCE is not optional here: MCP clients like Claude Desktop and Cursor are public clients that can't safely store a client secret, so the spec mandates PKCE for everyone.

4. Client requests a token bound to your resource (RFC 8707). It sends a resource parameter so the issued token's audience (aud) is specifically your server, not "any API this user can reach."

5. Client retries with the token:

POST /api/mcp HTTP/1.1
Host: opula.io
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Now you validate and serve.

Validating the token on the server

Whatever framework you use, token validation on a resource server comes down to the same checks. Here's the shape of it in a Node handler (Opula runs on Node on Vercel):

import { StreamableHTTPServerTransport }
  from "@modelcontextprotocol/sdk/server/streamableHttp.js";

async function authorize(req: Request): Promise<Claims> {
  const header = req.headers.get("authorization");
  if (!header?.startsWith("Bearer ")) throw new Unauthorized();

  const token = header.slice("Bearer ".length);
  const claims = await verifyJwt(token, { jwks: AUTH_SERVER_JWKS });

  // The checks that actually matter:
  assert(claims.iss === TRUSTED_ISSUER);            // who issued it
  assert(claims.aud === "https://opula.io/api/mcp"); // issued FOR us (RFC 8707)
  assert(claims.exp > nowSeconds());                 // not expired
  assertScopes(claims.scope, requiredScopes(req));   // allowed to do this

  return claims;
}

The audience check (aud) is the one people drop, and it's the one that stops the scariest attacks. Which brings me to the mistakes.

The three anti-patterns I had to design around

1. Token passthrough - explicitly forbidden. The tempting shortcut is: let the client hand you a token for some downstream API (say a brokerage PAT) and just forward it. The spec says MUST NOT. If you accept tokens that weren't issued for you, you break audit trails, blur identities in downstream logs, and turn your server into a proxy for stolen tokens.

The fix is a design rule: the MCP server is the system of record. Clients authenticate to you with MCP-scoped credentials; you then use your own managed credentials to call downstream services. Opula calls its market-data sources (like the FRED economic data API) with server-side keys that never touch the client - which, conveniently, is exactly what "no token passthrough" demands.

2. The confused deputy. If your server uses a single static client ID to talk to a third-party provider on behalf of every user, that provider may skip the consent screen for a request that looks trusted. An attacker can ride that to get a user authorized to something they never intended. Mitigation: dynamic client registration and explicit user consent, strict redirect-URI validation.

3. Forgetting you're on a network. Two cheap but critical HTTP-transport rules from the spec: validate the Origin header on every connection (prevents DNS-rebinding attacks), require HTTPS in production, and if you ever run locally, bind to 127.0.0.1 rather than 0.0.0.0. One more from hard-won ops experience: scrub the Authorization header out of your logs. It's a bearer token; logging it is the same as logging a password.

The pragmatic path: start with bearer, grow into OAuth

Here's the honest part. Full RFC 9728 + 8414 + 7591 + 8707 + PKCE is the destination, not necessarily your day-one commit. Plenty of shipping MCP servers - Opula included - start with a validated bearer token over Streamable HTTP: the client sends Authorization: Bearer <token>, middleware verifies signature, issuer, audience, expiry, and scope before the request ever reaches the MCP transport layer, and everything not explicitly authorized gets a clean 401.

That gets you a secure, multi-user server today. The value of understanding the full spec is that it tells you exactly where the seams are when you grow: the day a client wants to self-register, or an enterprise wants its own IdP to issue the tokens, you already know which RFC slots in where instead of re-architecting.

TL;DR

Pick your transport first. STDIO = local, use env vars, skip OAuth. Streamable HTTP = remote, you own auth.
Your MCP server is an OAuth 2.1 resource server, not an identity provider. It validates tokens; it doesn't mint them.
Discovery is mandatory now: 401 + WWW-Authenticate -> Protected Resource Metadata (RFC 9728) -> auth server -> Authorization Code + PKCE -> audience-bound token (RFC 8707).
Always check aud. A token not issued for your server is a token you must reject.
Never do token passthrough. Be the system of record; use your own downstream credentials.
You can ship a validated bearer token today and grow into the full flow - as long as you know where the seams are.