Listing a remote MCP server in every directory: what each one actually checks

Description and use

Successfully listed a remote MCP server across multiple directories, learned each directory’s requirements, and automated the process via registry publication and CI checks.

Problem

Getting a remote MCP server listed across multiple directories was fragmented and time‑consuming, with each directory having its own submission workflow and validation rules.

Outcome

The team successfully listed the MCP server in multiple directories, learned each directory’s validation logic, and streamlined the process by publishing a registry record first and automating CI checks where possible.

Workflow

• 1. Publish identity in official MCP Registry with DNS authentication.
• 2. Verify entry in Glama connector list.
• 3. Submit to MCP.Directory via GitHub repo (failed due to no public code).
• 4. Add entry to awesome‑remote‑mcp‑servers CI workflow, ensuring 401/403 response and connector badge.
• 5. Add gemini‑cli‑extension topic and manifest to GitHub repo for Gemini CLI gallery.
• 6. Submit to GitHub MCP gallery (manual curation).
• 7. Submit to Claude connectors via admin portal and correct inventory mismatch.
• 8. Update listing on mcp.so, handling HTTP 200 with application‑level errors.
• 9. Pay for official listing on MCP Market and verify live status.

Evidence

The Save button did nothing. We opened the network panel. The request had returned HTTP 200.

Source

Our PR was prepared by an agent, so we used it.

Source

The connector listing appeared about ten minutes after we submitted it on September 8.

Source