DEV Community: tinycoder-studio

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

tinycoder-studio — Sun, 13 Sep 2026 03:28:36 +0000

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

TL;DR: OpenSea runs an undocumented MCP server at mcp.opensea.io/mcp. One of its tools hands out API keys to anyone who asks, and another lets you resolve any Ethereum address with an OpenSea profile to its owner's username. Reported to Bugcrowd, now sharing the story and a free recon kit.

The Setup

I was poking around OpenSea's tooling one afternoon — just trying to understand how some of their internal features worked. Nothing fancy, no scanners, no brute force. Just curiosity and a browser.

That's when I stumbled onto something that wasn't meant for public eyes: an undocumented MCP server sitting at mcp.opensea.io/mcp.

At first glance it looked like just another internal API. But one particular tool caught my attention: get_instant_api_key.

The Discovery

Turns out, that little endpoint was an unintended exposure of something far more valuable. By sending a straightforward POST request to https://api.opensea.io/api/v2/auth/keys, I could pull a valid API key straight out of the server. No authentication hoops — just a direct line to a credential that should have stayed hidden.

With that key in hand, I called the get_profile tool and, suddenly, I could look up a username for any Ethereum address with an OpenSea profile. I tested it on my own wallet, then on a well-known one. Both resolved instantly.

It felt like finding a master key to a building you weren't supposed to enter.

Why This Matters

Information disclosure like this isn't just a curiosity — it's a useful starting point for attackers. Enumerating usernames might seem harmless, but it's often the first step in mapping out a target's footprint:

Tie a wallet to a real identity (doxxing vector)
Correlate multiple wallets to one person
Build a profile for targeted phishing or social engineering

For NFT holders, that's a real privacy concern. Your wallet is supposed to be pseudonymous — this tool weakens that pseudonymity.

What OpenSea Did Right

To be fair, not everything on that server was exposed. The sensitive tools — like cancel_orders — properly required a wallet JWT with write:orders scope. Trying to call them without it returned a clean MISSING_SCOPE error.

So the architecture is sound. The gap was in the discovery layer: a handful of tools were reachable with just an API key that anyone could mint.

The Responsible Disclosure

I reported this to OpenSea's Bugcrowd program with a full write-up and PoC. It's now in their triage queue (self-assessed as P4 informational — username enumeration; official severity pending triage).

I have no affiliation with OpenSea or Bugcrowd.

If you're a security researcher: don't go poking at this yourself. It's been reported, and testing live systems without authorization is both against program rules and a great way to get banned.

The Free Recon Kit

I turned the whole investigation into a free PDF — the OpenSea MCP Server Recon Kit — with the methodology, the tools I enumerated, and the lessons learned. It's pay-what-you-want (free, $0 minimum), and it's the same playbook I use when auditing any undocumented API surface. The kit contains methodology only — no exploit code:

👉 Download the free recon kit

The Bigger Lesson

Undocumented internal APIs are everywhere. They're often overlooked during security reviews, yet they can leak exactly the kind of secrets — like API keys — that turn a minor misconfiguration into a real problem.

The next time you're auditing a target, ask yourself: what endpoints exist that nobody documented? That's where the interesting stuff hides.

This technique was reported to Bugcrowd and is shared here for educational purposes only.

Found this useful? Follow me for more bug bounty write-ups and recon methodology.

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

tinycoder-studio — Sat, 12 Sep 2026 23:52:09 +0000

The Setup

I was poking around OpenSea's tooling one afternoon — just trying to understand how some of their internal features worked. Nothing fancy, no scanners, no brute force. Just curiosity and a browser.

That's when I stumbled onto something that wasn't meant for public eyes: an undocumented MCP server sitting at mcp.opensea.io/mcp.

At first glance it looked like just another internal API. But one particular tool caught my attention: get_instant_api_key.

The Discovery

It felt like finding a master key to a building you weren't supposed to enter.

Why This Matters

Information disclosure like this isn't just a curiosity — it's a goldmine for attackers. Enumerating usernames might seem harmless, but it's often the first step in mapping out a target's footprint:

Tie a wallet to a real identity (doxxing vector)
Correlate multiple wallets to one person
Build a profile for targeted phishing or social engineering

For NFT holders, that's a real privacy concern. Your wallet is supposed to be pseudonymous — this tool quietly erases that.

What OpenSea Did Right

So the architecture is sound. The gap was in the discovery layer: a handful of tools were reachable with just an API key that anyone could mint.

The Responsible Disclosure

If you're a security researcher: don't go poking at this yourself. It's been reported, and testing live systems without authorization is both against program rules and a great way to get banned.

The Free Recon Kit

👉 Download the free recon kit

The Bigger Lesson

The next time you're auditing a target, ask yourself: what endpoints exist that nobody documented? That's where the interesting stuff hides.

This technique was reported to Bugcrowd and is shared here for educational purposes only.

Found this useful? Follow me for more bug bounty write-ups and recon methodology.

I Rewrote 5 AI-Generated Paragraphs to Sound Human — Here's the Before & After

tinycoder-studio — Thu, 10 Sep 2026 00:13:37 +0000

Last week I wrote about building an AI humanizer that actually sounds human. @topstar_ai pointed out the hardest challenge — and they're right. The hardest part isn't making AI text longer. It's making it feel like someone actually meant what they wrote.

Here's what I found.

1. Uniform rhythm. Every sentence is 12-18 words. Humans vary wildly — some thoughts are three words, others spill across two sentences.

2. Hedging and filler. "It's important to note that..." "In today's world..." These phrases add zero meaning and scream template.

3. Empty transitions. "Furthermore," "Moreover," "Additionally" — humans say "also" or just skip the transition entirely.

None of these are wrong. They're just empty. And once you spot them, you can't unsee them.

1. Product description (generic SaaS pitch)

AI: Our platform provides a comprehensive suite of tools designed to help teams collaborate more effectively and streamline their workflow.
Human: It helps teams stop chasing each other across Slack threads.

Annotation: Cut the feature list. Gave it a problem and a punch.

2. Blog intro (the classic "In this article, we'll explore...")

AI: In this article, we will explore the top trends shaping the future of web development in 2025 and beyond.
Human: Web dev moved fast in 2024. Here's what actually mattered.

Annotation: Killed the meta-commentary. Started mid-thought like a human would.

3. Social media post (LinkedIn thought-leadership)

AI: Furthermore, it is important to recognize that leadership in today's world requires adaptability and a commitment to continuous learning.
Human: Adapt or die. That's been true forever — but most people still skip the uncomfortable part.

Annotation: Removed "furthermore" and "it is important to recognize." Added an opinion.

4. Email outreach (cold template)

AI: I hope this message finds you well. I am reaching out to introduce our product, which I believe could be of great value to your organization.
Human: Your site's load time is 4 seconds. Here's how to cut it to 1.

Annotation: No greeting, no filler. Led with a specific number they can't ignore.

5. Error message / technical explanation

AI: An unexpected error has occurred. Please try again or contact support if the issue persists.
Human: Something broke on our end. We're fixing it — refresh in 30 seconds and it should work.

Annotation: Added a timeframe and ownership. Humans explain what's happening and when it ends.

Human writing has opinions, rhythm changes, and friction. AI writing is smooth, safe, and forgettable.

That's the whole game. If you're tired of generating text that reads like a committee wrote it, check out PseudoHuman at toolbox-lilac-three.vercel.app — it takes your AI draft and injects the personality it's missing.

What's the tell-tale sign that makes you stop reading something that sounds AI-generated?

I'm Building an AI Humanizer That Actually Sounds Human — Here's What I'm Learning

tinycoder-studio — Wed, 09 Sep 2026 14:22:02 +0000

Hey — I'm building an AI humanizer in public, and I wanted to share what I'm learning before there's anything to launch.

The problem I'm seeing

Most "humanizers" I've tried just swap synonyms. You know the output instantly:

"Utilize" instead of "use." Perfect grammar. Zero rhythm. Every sentence the same length.

It passes a thesaurus check and fails the human check. Real people write messy — fragments, dashes, short punches after long rambles. That's what I'm trying to capture.

What I'm building (honestly, still early)

No beta yet. No launch. I'm building a small tool that rewrites AI-sounding text so it aims to sound like a person wrote it — rhythm, burstiness, tone shifts, not just word swaps.

Right now I'm just testing in the open and learning from real examples.

What surprised me so far

Rhythm beats vocabulary. Varying sentence length does more for "sounds human" than any synonym swap.
Imperfection is a feature. A fragment. An em dash. A blunt short sentence. Readers trust it more.
Context matters more than cleverness. Same input needs a different rewrite for an essay vs. a tweet vs. an email.

A tiny before/after (from my own testing notes, still rough)

Before (typical AI):

"In today's fast-paced world, it is important to utilize effective tools for content creation."

What I'm aiming for:

"Everyone's drowning in AI-sounding content. I'm trying to make mine sound like I actually wrote it."

Still rough. That's the point of building in public.

What I want from you

Drop a sentence that screams AI in the comments — I'll reply with how I'd approach rewriting it, and what I'd still get wrong. Teaching in the open, learning in the open.

If you want a note when the early access list opens, follow along. No spam, just the build log.

Vanilla JavaScript PWA Tutorial: Build With Zero Dependencies

tinycoder-studio — Mon, 07 Sep 2026 10:05:39 +0000

Every PWA tutorial starts with "install React, then Next.js, then configure Webpack..." By the time you're done, you have 200MB of node_modules for a to-do app.

This tutorial uses zero dependencies. Just HTML, CSS, and JavaScript. You'll have a working PWA in 10 minutes.

What We're Building

A simple web app that:

Works offline
Installs to the home screen
Has a service worker for caching
Runs on any static host (Vercel, Netlify, GitHub Pages)

Step 1: The HTML

Create index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My PWA</title>
  <link rel="manifest" href="/manifest.json">
  <meta name="theme-color" content="#0F172A">
  <link rel="apple-touch-icon" href="/icon-192.png">
</head>
<body>
  <h1>Hello, PWA!</h1>
  <p>This app works offline.</p>
  <script src="/app.js"></script>
</body>
</html>

Step 2: The Manifest

Create manifest.json:

{
  "name": "My PWA",
  "short_name": "PWA",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#0F172A",
  "theme_color": "#06B6D4",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Step 3: The Service Worker

Create sw.js:

const CACHE = 'my-pwa-v1';
const ASSETS = ['/', '/index.html', '/app.js', '/style.css'];

self.addEventListener('install', e => {
  e.waitUntil(
    caches.open(CACHE).then(cache => cache.addAll(ASSETS))
  );
});

self.addEventListener('activate', e => {
  e.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.filter(k => k !== CACHE).map(k => caches.delete(k)))
    )
  );
});

self.addEventListener('fetch', e => {
  e.respondWith(
    caches.match(e.request).then(r => r || fetch(e.request))
  );
});

The service worker does three things:

Install — caches all app files
Activate — deletes old caches
Fetch — serves from cache, falls back to network

Step 4: Register the Service Worker

Create app.js:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered:', reg.scope))
    .catch(err => console.log('SW failed:', err));
}

Step 5: Deploy

If you're using Vercel:

npm i -g vercel
vercel deploy --prod

That's it. Your PWA is live.

Testing Offline

Open Chrome DevTools → Application → Service Workers
Check "Offline" in the Network tab
Refresh the page — it should still load
On Android: three-dot menu → "Add to Home Screen"

Why Vanilla JS?

Zero dependencies — nothing to update, nothing to break
Fast — no build step, no transpilation
Small — the entire app is under 10KB gzipped
Understandable — you can read every line

React and Next.js are great for complex apps. But for a simple PWA? Vanilla JS is enough.

Want a head start?

TinyCoder is a vanilla JS PWA with 5 offline dev tools. Config-driven, deployable in minutes.

Originally published at toolbox-lilac-three.vercel.app/blog/vanilla-js-pwa-tutorial.html