Kroy MCP Marketplace

Publishing guidelines

How to publish an MCP server on the Kroy MCP Marketplace, and what makes a listing people trust.

Before you start

You need:

  • A working MCP server. Either a remote endpoint people connect to over HTTPS, or a local package people run themselves (npm, PyPI or a Docker image).
  • An account. Sign in with a passkey. Your handle is your public publisher name, so choose the one your users know you by.
  • Five minutes to describe it honestly. Most review rounds are caused by a missing data-handling statement or a vague description.

Remote or package?

Remote endpoint Local package
People connect with a URL a command they run
Kroy reads your tools yes, by connecting no, you declare them
Kroy re-checks it every six hours on submission and on request
Needs sign-in? optional (OAuth recommended) configuration variables

Use Streamable HTTP for remote servers. The older HTTP+SSE transport is accepted but marked as older.

What to include

Name and summary

  • Name: what people will call it. Don't use another company's brand as if it were yours: "Weather for Xero users" is fine; "Xero Official" is not, unless you are Xero.
  • Summary: one line, under 160 characters, saying what it does. "Read and draft invoices in Xero" beats "The ultimate AI-powered accounting assistant".

Description

Say what the server does, who it is for, and anything people should know before connecting it: limits, costs, regions and required accounts. Plain text; blank lines make paragraphs.

Tools

  • Remote servers without sign-in: Kroy reads your tools when it connects. Make sure every tool has a clear description, since people and AI models both rely on it.
  • Packages, and remote servers that need sign-in: list your tools yourself, one per line, as name — what it does. If Kroy later reads the tools and finds some missing, the listing shows a warning.
  • Mark your tools. Use MCP tool annotations: readOnlyHint: true for tools that only read, and destructiveHint: true for tools that delete or overwrite. Listings show these, and with the Kroy app organisations will be able to require approval for tools that change data.

Data handling (required)

State plainly:

  • what data the server receives from the AI client;
  • what it stores, and for how long;
  • where it sends data (which third-party APIs, and in which region);
  • whether any of it is used to train models.

Example: "Receives the postcode in each request. Stores nothing. Calls the Met Office DataPoint API (UK). No data is used for training."

Configuration

List every environment variable or setting, and mark secrets. Never put a real key in a listing.

Trust details

  • Source repository: optional, but a public repository helps people and reviewers.
  • Licence: for example MIT, Apache-2.0 or "Proprietary".
  • Support contact: an email address or URL you actually monitor.
  • Tested with: only the clients you have actually tried.

Import from an MCP Registry server.json

If you already have a server.json for the official MCP Registry, paste it into Import on the publish page. Kroy fills in what it can: name, description, version, remotes or packages, and environment variables. You then add what the registry format doesn't cover, such as data handling, tools, licence and support.

Submitting

  1. Fill in the form, or import, then choose Submit for review. Save draft keeps it private.
  2. Kroy runs its checks straight away. You see the results in your dashboard.
  3. A reviewer reads the listing, usually within one or two working days. How review works.
  4. You are told the outcome in your dashboard (and by email, once email is enabled): approved, changes requested with a note, or not accepted with a reason.

Updating a listing

Edit it from your dashboard and submit again. The version people see stays live while the update is reviewed, and your update replaces it once approved. Keep the version number meaningful; people see it.

You can unlist a server at any time (it disappears from search but its page still works) and relist it later.

Ratings

People who have used your server can say it works or it didn't work, name the AI client they used, and add a short note. You cannot rate your own server. Ratings older than a year stop counting. If a rating says something is broken, fix it and use Re-check so the listing shows it is working again.

Checklist

  • The summary says what the server does, in one line.
  • Every tool has a description, and read-only or destructive tools are annotated.
  • The data-handling statement answers: receives, stores, sends, trains.
  • Secrets are marked, and no real keys appear anywhere.
  • The remote endpoint passes Kroy's checks, or the package exists on its registry.
  • The support contact works.