MCP Server Directory Listings: A Deep Dive into Validation Checks

The Elusive Save Button: A Validation Nightmare

The seemingly simple act of listing a remote MCP server across various directories can devolve into a frustrating technical scavenger hunt. At GoodBarber, we encountered this firsthand while attempting to register our MCP server, which facilitates app management via an authenticated connection. The initial hurdle was not a lack of functionality, but the opaque nature of the validation processes employed by different platforms. A critical moment arrived when the "Save" button on a submission form yielded no visible action. Network analysis revealed an HTTP 200 response, indicating success, yet the server listing failed. The culprit? A validation error on a form field that was not even displayed to the user. This hidden requirement turned a quick task into a multi-day debugging session.

The disparity in submission times was stark. One directory processed our submission in approximately ten minutes, a smooth experience. Another, a GitHub list, accepted our endpoint after a successful 401 (Unauthorized) challenge, implying a different security-focused validation. Yet others, requiring human review, left our submission in limbo for an indeterminate period. This inconsistency highlighted that "getting the server listed" is not a singular task but a collection of distinct, platform-specific integration jobs, each with its own peculiar requirements and validation logic.

Understanding MCP Server Directory Checks

Our MCP server is designed for secure, authenticated management of applications. It is hosted, requires OAuth for access, and critically, does not expose its server code publicly for directories to scan. This architectural choice means that directories cannot simply crawl a public repository to verify the server's existence or functionality. Instead, they rely on a series of checks that probe the server's public-facing API and its adherence to specific protocols. These checks can be broadly categorized:

1. Endpoint Availability and Basic Responsiveness

The most fundamental check is whether the provided server endpoint is reachable and responds to standard HTTP requests. A successful HTTP 200 OK response is the baseline. However, as we discovered, a 200 response doesn't guarantee a successful submission. Many directories will perform deeper checks that go beyond mere reachability. They might send specific request payloads or query parameters to ensure the server can handle expected interactions. A server that times out, returns a 5xx error, or fails to respond within a reasonable timeframe will likely be rejected at this stage.

2. Authentication and Authorization Protocols

Given that our MCP server relies on OAuth, this becomes a significant validation point for many directories. They need to verify that the server correctly implements OAuth 2.0 flows, including:

• Authorization Endpoint: The directory must be able to reach the server's authorization endpoint to initiate the OAuth flow.
• Token Endpoint: Verification of the token endpoint's ability to issue access tokens upon successful authorization.
• Scope Validation: Some directories might check if the server properly handles requested scopes, ensuring it only grants access to the permissions specified.
• Client Authentication: The directory will likely test how the server authenticates the client (the directory itself) during the OAuth handshake. Our experience with the GitHub list accepting a 401 response suggests that some platforms specifically test the server's ability to reject unauthenticated or improperly authenticated requests, which is a crucial security check.

3. Data Schema and Field Validation

This is where the hidden complexities often lie. Directories expect the MCP server to adhere to a specific data schema for configuration and metadata. When a server is submitted, the directory attempts to parse and validate this data. This can involve:

• Required Fields: Ensuring all mandatory fields are present in the submission payload. This was the root of our "hidden field" problem. The form did not display a field that the backend validation logic required.
• Data Types and Formats: Checking that fields contain data of the expected type (e.g., string, integer, boolean) and adhere to specific formats (e.g., valid URLs, specific date formats).
• Value Constraints: Verifying that field values fall within acceptable ranges or specific enumerated lists. For example, a server might need to support a particular version of a protocol, or a specific encryption standard.