Add neo-x402-mcp: AI-powered web intelligence toolkit with x402 monetization

[atakanelik34]

Neo x402 MCP Server

AI-powered web intelligence toolkit with pay-per-use monetization via x402 protocol.

Tools

• web_search — Web search with AI-powered ranking
• scrape — Anti-bot web scraping with Cloudflare bypass
• pdf_analyze — PDF content analysis and summarization
• crypto_price — Real-time cryptocurrency prices
• code_review — AI-powered code review

Details

• Remote URL: https://neo.docly.work/mcp
• Transport: streamable-http
• Network: Base mainnet (eip155:8453)
• Registry: Already published to official MCP Registry (io.github.atakanelik34/neo-x402-mcp)

Repository

https://github.com/atakanelik34/neo-x402-api-server

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c2cf94c807

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Nest publisher metadata under the remote URL key

ToolHive’s extension readers expect _meta["io.modelcontextprotocol.registry/publisher-provided"]["io.github.stacklok"][<extension-key>], where for remote servers <extension-key> is remotes[0].url (see internal/serverjson/extensions.go ExtensionKey()/GetExtensions()). Here the metadata is placed directly under the namespace object, so the catalog tooling will treat this server as having no extensions (e.g., last_updated/stars won’t be read and tools/tags won’t flow through extension-aware paths).

Useful? React with 👍 / 👎.

[rdimitrov]

The feedback given by chatgpt is correct, the nesting is not what we expect, let's update and fix that 👍

[JAORMX]

Hey @atakanelik34, thanks for the submission! I took a look and unfortunately there are quite a few things that need to be addressed before we can consider this for the catalog.

The big blocker

The source repository (https://github.com/atakanelik34/neo-x402-api-server) is completely empty... zero commits, no code, no license. We need to be able to verify what a server actually does before listing it. This is a hard requirement per our registry inclusion criteria — source code must be publicly available.

server.json spec issues

Running task catalog:validate fails because the description exceeds the 100-character limit (yours is ~155 chars). But there's more:

1. name must use our namespace: io.github.stacklok/neo-x402-mcp, not io.github.atakanelik34/neo-x402-mcp
2. _meta nesting is wrong (as @rdimitrov already pointed out). The publisher key must be io.github.stacklok, and the extension key must match remotes[0].url exactly. So the structure should look like:

   "_meta": {
     "io.modelcontextprotocol.registry/publisher-provided": {
       "io.github.stacklok": {
         "https://neo.docly.work/mcp": {
           "tier": "Community",
           "status": "Active",
           "overview": "## Neo x402 MCP\n\n...",
           ...
         }
       }
     }
   }

   Check out registries/toolhive/servers/stripe-remote/server.json for a working example of a remote server entry.
3. metadata.* fields must be removed — metadata.last_updated and metadata.stars are auto-populated by CI. Never add them manually.
4. icons array is missing from the top-level fields
5. icon.svg file is missing from the PR entirely
6. overview field is missing inside the extension block (should start with ## Title\n\n + 3-5 sentences)
7. Tags should include "remote" since this is a remote server
8. packages: [] — just remove this field for remote servers
9. Missing newline at end of file

Concerns that need discussion

Beyond the spec issues, there are a couple of things the maintainer team would need to think through:

• x402 pay-per-use over crypto: Users connecting to this server could incur real financial costs on Base mainnet without realizing it. That's... not great for discoverability in a catalog where people expect to try things out. At minimum this would need very clear disclosure.
• "Cloudflare bypass" scraping: The PR description mentions anti-bot scraping with Cloudflare bypass. This could put users in a tricky spot with ToS compliance.
• No source to audit: With an empty repo, there's no way to verify what the remote endpoint actually does with requests.

What to do

The empty repo is the biggest issue. Please push your source code, add a license (we accept Apache-2.0, MIT, BSD-2-Clause, BSD-3-Clause), and then rework the server.json following the spec. The stripe-remote entry is a good template to follow.

Feel free to ping if you have questions about the schema!

[JAORMX]

Hey @atakanelik34, thanks again for your interest in contributing to the catalog!

After reviewing this against our registry inclusion criteria, we're going to close this one out. The core blocker is that the source repository is empty (zero commits, no code, no license). Our criteria require publicly available source code with a permissive license... that's a hard requirement we can't waive.

If you publish the source code and address the schema issues mentioned in the review, you're welcome to open a new PR. The stripe-remote entry is a solid template to follow for remote servers, and our adding entries guide walks through the full schema.

Thanks for your time!