Getting your MCP server listed on Glama

Submission requirements

Glama accepts both locally-installable (stdio) servers submitted via their GitHub repository and remote (HTTP/SSE) servers submitted via endpoint URL. The requirements differ:

For remote servers, the endpoint URL must be HTTPS with a valid certificate from a public CA. Self-signed certificates fail immediately. The endpoint must accept POST requests at the URL you provide (for streamable HTTP transport) or accept SSE connections (for the older SSE transport). Glama's scanner follows redirects up to 3 hops but prefers stable, non-redirecting URLs.

For stdio servers, Glama reads your repository's README, package.json (or pyproject.toml), and any MCP-specific manifest file. It may perform static analysis of your tool definitions to extract the tool list without running the server. A repository with clear documentation, a working install command in the README, and well-typed tool definitions (using Zod or JSON Schema) will score better than one that requires reading the source code to understand what tools are available.

What Glama's scanner checks for remote servers

When you submit a remote endpoint, Glama runs a verification sequence similar to what AliveMCP runs on every 60-second probe cycle:

# Step 1: TLS verification
# Glama checks: certificate valid, not expired, chain to public CA, SAN matches hostname
openssl s_client -connect your-server.example.com:443 -servername your-server.example.com &1 \
  | grep -E "Verify return code|subject|issuer"

# Step 2: MCP initialize handshake
curl -s -X POST https://your-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": { "tools": {} },
      "clientInfo": { "name": "glama-scanner", "version": "1.0" }
    }
  }'

# Glama expects: { "jsonrpc": "2.0", "id": 1, "result": { "protocolVersion": "...", "serverInfo": { "name": "...", "version": "..." }, ... }}

# Step 3: Tool list retrieval
curl -s -X POST https://your-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

# Glama expects: { "result": { "tools": [ { "name": "...", "description": "...", "inputSchema": {...} } ] } }

Each step must succeed for your server to receive a "Verified" badge. The most common failure at the initialize step is a server that handles the HTTP request but does not process the JSON-RPC method correctly — returning an HTTP 200 with an empty body or an HTML error page instead of a JSON-RPC response. Test with the curl commands above before submitting.

Writing tool descriptions that rank in Glama's search

Glama indexes your tool names and descriptions for its internal search. When a developer searches "analytics MCP server" or "query database MCP", Glama matches against your tool descriptions. Descriptions that are vague or self-referential ("This tool is part of our MCP server") do not match meaningful queries.

Good tool descriptions for Glama follow a pattern: [verb] + [object] + [constraints or context].

The description appears on your Glama listing card and in search results. Keep the most important information in the first 120 characters — the rest may be truncated in card views. The full description is available on the tool's detail page and is indexed for search regardless of length.

Maintaining your Glama listing after approval

Glama re-scans listed servers periodically. A server that was healthy at submission time can lose its verified badge if subsequent scans find it unreachable or non-compliant. The consequences:

• Unverified servers are deprioritized in Glama's search results relative to verified ones.
• Servers with repeated scan failures may be delisted entirely, requiring re-submission.
• Users see an "unhealthy" or "unverified" status badge on your listing, which reduces installs.

The gap between Glama's scans means you can have an outage, recover, and not know Glama caught it — until you see your listing lose its badge. AliveMCP fills this gap with 60-second protocol probes: the same initialize + tools/list sequence Glama's scanner runs. When AliveMCP alerts you to a failure, you have time to investigate and recover before Glama's next scan runs.

// Add a dedicated /healthz endpoint for monitoring tools
// This does NOT replace AliveMCP's protocol probe — it supplements it
app.get('/healthz', async (req, res) => {
  try {
    // Verify that the MCP server transport is up and accepting connections
    // A 200 here means the HTTP layer is healthy
    res.json({
      status: 'ok',
      server: process.env.npm_package_name,
      version: process.env.npm_package_version,
      uptime: process.uptime(),
    });
  } catch (err) {
    res.status(503).json({ status: 'error', message: err.message });
  }
});

// Note: AliveMCP probes the MCP protocol layer (initialize + tools/list), not /healthz
// Both checks are complementary — HTTP health covers process health, protocol probe covers MCP compliance

Related questions

Further reading

• Universal MCP registry requirements — what all registries check
• MCP server Smithery listing — smithery.yaml and submission guide
• MCP server PulseMCP — GitHub-based discovery and listing
• MCP server tool design — writing descriptions that rank and convert
• MCP server authentication — when and how to add auth to a public server
• MCP server SSL certificate — keeping your TLS cert valid for registry scans
• AliveMCP — continuous protocol monitoring between Glama's re-scans