Input: a server implementation, a declared protocol revision, and a named intended host. Output: publication and compatibility evidence for that combination. This is an implementation checklist, not a universal MCP certification or a claim that ByAgents hosts an MCP service.

Distinguish five milestones

MilestoneEvidence to retain
PublishedA retrievable metadata record and the actual package or remote endpoint
Available in a hostThe intended catalog or configuration can expose the server
ConnectedAuthentication and protocol exchange succeed for the intended user
SelectedA realistic task chooses the appropriate exposed tool
CompletedThe final output or authorized external state is correct

Passing one row does not imply the next. A listing can exist even when a host does not consume its registry. A connection can succeed while every useful tool call fails.

Pin the compatibility boundary

The MCP versioning documentation currently identifies revision 2026-07-28. It uses per-call protocol versions, including _meta["io.modelcontextprotocol/protocolVersion"]; Streamable HTTP also carries the MCP-Protocol-Version header. Older revisions use a different lifecycle. Versioning reference.

Record the server release, SDK release, host release, transport, protocol revision, and authentication method. Use the supported SDK and specification for that combination. Do not combine code from different revisions without an explicit compatibility layer and tests.

Understand server discovery precisely

In the 2026-07-28 specification, server/discover provides server identity, capabilities, and supported versions. Servers implement it; clients need not call it before every other operation. This is discovery of a known server's properties, not a web search for businesses. Discovery specification.

The distribution question remains: how did the host obtain this server's address or package in the first place? Record that route independently, such as a user installation, organization configuration, catalog entry, or another supported mechanism.

Publish metadata that agrees with the runtime

The official MCP Registry describes itself as a preview metadata service. Namespace ownership is distinct from a security endorsement, and registry metadata is distinct from executable code. Follow its current publisher requirements and the intended downstream consumer's admission process. Registry overview.

Verify the identity, package or endpoint, version, documentation links, and installation instructions against the release being distributed. Do not put a private credential in public metadata. Test a clean installation path rather than relying on the maintainer's already-configured environment.

Test selection and completion separately

Provide a small set of task-focused tools with precise descriptions. Include inputs, output meaning, limits, side effects, and a bounded recovery path. Test both a task the tool should handle and one it should reject. Confirm that asynchronous work includes a documented route to the final result.

Require authorization for consequential operations. Record the actual completion artifact rather than the model's claim that the tool worked. If a host hides internal selection traces, mark the selection rationale unknown rather than fabricating it.

A task-focused tool definition

This fictional tool definition illustrates a read operation using the MCP tool shape. It is not a complete server, a JSON-RPC request, or a claim of a working integration. The implementation must enforce the stated account boundary and return the documented states.

json
{
  "name": "get_extraction_result",
  "description": "Read an existing invoice extraction job owned by the authenticated account. Returns its processing state and, when succeeded, the extracted line items. Does not create a job or charge for another extraction.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "job_id": {
        "type": "string",
        "minLength": 1,
        "description": "The identifier returned when this account created the extraction job."
      }
    },
    "required": ["job_id"],
    "additionalProperties": false
  }
}

The versioned tools specification defines the actual envelope, schemas, and request requirements. Keep the creation operation separate and document its charging boundary. For a complete implementation, also define the result schema, authorization failures, unknown identifiers, and retention expiry. The example's description should be tested against behavior, not trusted as an enforcement mechanism.

Release record

json
{
  "example": true,
  "server_release": "example-1.0.0",
  "host": "not_tested",
  "host_release": null,
  "protocol_revision": "2026-07-28",
  "transport": "streamable_http",
  "publication": "not_verified",
  "authentication": "not_verified",
  "task_completion": "not_executed",
  "independent_discovery": "unknown"
}

Replace unknown values only with observations. Recheck the affected consumer after authentication, protocol, package, or tool-schema changes. A versioned record makes a narrow compatibility claim useful without pretending it covers every agent application.

Primary sources