# Your MCP Connector Works. Here Is What Getting Listed Takes

A working MCP server still needs documentation, privacy details, support and review. Follow the listing steps and the customer tests that come after publication.

Author: J.A. Watte
Published: November 6, 2026
Source: https://jwatte.com/blog/mcp-connector-listing-small-business/

---

**A working connector still needs a public explanation, accurate privacy details, a support contact, owner declarations and a route into each assistant. Then it needs testing through the published listing. This guide follows a completed submission and gives other businesses a checklist they can adapt.**

An owner asks an AI assistant to book a room at their own motel. The assistant declines, then supplies a specification for making the website ready. In our lodging example, both Google AI Mode and Gemini did this. The twelve-property group already had the suggested discovery files, booking markup, a read-only MCP server and browser form tools. One suggested booking address would not even have worked.

The missing work involved distribution and the information a reviewer needs. Google's hotel panels lacked a rate from the business. The connector lacked a human documentation page and a receiving support mailbox. MCP, or Model Context Protocol, lets an assistant call a named function such as "check availability." A directory helps someone find and connect that function. Neither automatically gives the business access to a platform's booking system.

## Start with the whole checklist

Download the [MCP connector listing kit](/downloads/mcp-connector-listing-kit.md) for a worksheet, form preparation, documentation outlines and repeatable tests.

| Prepare | Why it matters | What the lodging example needed |
|---|---|---|
| Public documentation | A reviewer needs setup, inputs, examples, limits and help in one readable place | A new human page alongside the existing machine-readable files |
| Connector privacy section | People need to know what actually reaches the business | A description checked against request handling and logging code |
| Receiving support mailbox | A listed contact must accept a question or failure report | Receiving mail enabled and an MX record added, then a delivery test |
| Server title and friendly inputs | People should recognise the business and enter ordinary names | A human title and unique short property names of at least three characters |
| Small read-only tools | Reviewers need to understand each action and its inputs | Four tools, with titles and annotations, asking only for stay details |
| Accurate descriptions | An assistant uses the words to explain the answer | Rounding and line-item wording corrected without changing prices |
| Enforced human steps | A direct request must respect the same boundary as the page | Agreement and signature checks moved into server validation |
| Test instructions and prompts | Someone outside the business must reproduce the promised result | Every tool exercised through a custom connector |
| Owner declarations | Submission includes statements of responsibility | The owner reviewed and made the declarations personally |

An annotation is a machine-readable label, such as `readOnlyHint`, that describes a tool's effect. Treat it like the label on a switch: check that the wiring agrees. A read-only availability tool should never hold a room or store a customer's draft.

## Write the documents from the behaviour

The documentation page should explain what the connector does, its connection address, how to connect, each tool's inputs and examples, its limits, data handling and support. Use a placeholder such as `https://example.com/mcp` while preparing your own instructions. A list of technical files is insufficient for someone trying to connect from an assistant's settings screen.

The lodging privacy section says the connector receives stay dates, room type and property name; it needs no account or personal details and does not receive the conversation. Its code writes a failure line identifying the tool or property and the error. The hosting provider processes requests, and booking happens on the business website. A build test now detects added logging so that those statements can be reviewed before release.

Those are observations about this implementation. Copy the structure and check your own code before making the same promises. Explain successful requests, failed requests, retention and providers separately. If a tool stores a draft or accepts a phone number, include that behaviour. Your developer should be able to point to the code behind each sentence.

Test the mailbox too. The lodging domain could send booking emails but had no receiving route. An MX record tells other mail systems where to deliver incoming mail. The business enabled receiving, added the record and confirmed delivery with a real message. Sending and receiving deserve separate checks.

## Make the answer and the human boundary agree

Friendly inputs reduce guesswork. The lodging tools accept an unambiguous short property name and ask which property the customer means when it could match several. The hub's quote tool relays the property's answer unchanged, keeping both totals aligned.

Words can introduce a price error even when the calculation is correct. One description implied rounding the daily amount before multiplying: $35.71 times seven produces $249.97. The code correctly multiplied nights by the $250 weekly rate divided by seven, then rounded once, producing $250.00.

Likewise, "3 days at $35.71 a day ($107.14)" became "3 extra nights at 3/7 of the $250 week ($107.14)." A six-night stay described as a week became "6 nights, capped at the $250 weekly rate." Tests compared every stay length from one to thirty nights; no price changed. Read each printed line as a customer would and make the arithmetic explainable.

The booking page required a signed agreement, but the server originally accepted enough information to hold a room without that signature. It now checks the agreement, typed name and drawn signature before holding anything. An empty signature pad can still produce a valid image, so image existence alone was insufficient.

WebMCP is a way for a webpage to offer named tools to a browser assistant. In this example, deriving a tool from the form exposed its agreement checkbox, signature-name field and anti-spam field. The replacement explicitly lists seven permitted fields: room type, check-in date, check-out date, guests, name, phone and email. The person handles agreement and signing. Keeping those fields out of the tool and enforcing them on the server are separate jobs.

## Claude's ten submission steps

The following sequence was observed on November 5 and 6, 2026. Check the [publishing guide](https://claude.com/docs/directory/publish) before starting. Submission requires a paid Claude plan; a Free account's ability to add one custom connector does not make it eligible to submit a directory listing. The submitting account or organisation owns the listing, so choose it deliberately.

Test the server as a custom connector first. Current instructions allow either its URL or an existing connection in the form. Open [directory management](https://claude.ai/directory/manage), choose **Submit new**, and choose **MCP connector**.

| Step | What to prepare |
|---|---|
| 1. Connection | Enter the URL or select the custom connector. The portal reads its live tools, resources and authentication; the example showed four tools, no resources and no authentication. |
| 2. Tools | Give every tool a title and the required effect annotations. Separate reading from writing. Check the detected definitions. |
| 3. Listing | Name, slug fixed once you submit, one-line summary up to 200 characters, description up to 2,000, up to five categories, author details, icon, documentation, support and privacy links. |
| 4. Use cases | Up to three examples, each with a prompt, prerequisites and whether it reads, writes or does both. |
| 5. Company | Business name, website and primary contact. |
| 6. Authentication | Check the detected sign-in method. Public-data tools can use no authentication. |
| 7. Data handling | Explain API ownership, personal health data and sponsored content. An API is the service a tool calls for its answer. |
| 8. Test and launch | Reproducible reviewer instructions and confirmation that every tool was run through MCP Inspector or as a Claude custom connector. |
| 9. Compliance | The owner reviews and makes the seven declarations below. |
| 10. Review and submit | Check the listing, submit and follow its status. Publish if the approval card asks you to. |

The declarations cover reading the guidelines; calling the business's own APIs; no transfers of money or financial assets; no AI generation of images, video or audio; no hidden instructions or directions about model behaviour in tool descriptions; no unnecessary conversation collection; and public documentation by publication. If a statement is untrue, stop and resolve eligibility. An assistant can prepare evidence, but the person makes the declaration and accepts consent screens.

The example received approval as a **community connector** after automated listing review, then was published. Community receives automated screening; Verified receives deeper functional review. Neither guarantees security or performance. This approval was Community. Read Claude's [verification explanation](https://claude.com/docs/connectors/verification). Some Community listings publish automatically; follow the [status card](https://claude.com/docs/directory/submission-status.md) and verify visibility.

## Publish the Registry entry separately

The [official MCP Registry quickstart](https://modelcontextprotocol.io/registry/quickstart) describes another route, currently in preview. Its entry records where a server lives. It does not itself complete an assistant's directory application.

1. Prepare `server.json` with the namespace name, human title, description, version and website URL. For a remote server, add a `streamable-http` remote pointing to its connection URL.
2. Prove control of the namespace. The [authentication guide](https://modelcontextprotocol.io/registry/authentication) covers GitHub identity and DNS proof for a reverse-domain name such as `com.example/booking-info`.
3. For DNS proof, publish the generated public key in the required TXT record, following the documented `v=MCPv1; k=ed25519; p=PUBLICKEY` format. DNS is the domain's public address book. Keep the signing key private.
4. Use `mcp-publisher` to validate, log in with the chosen method and publish. Inspect the resulting entry and version.

The lodging entry passed validation and showed active after publication. The kit includes a fill-in outline; check the [remote-server instructions](https://modelcontextprotocol.io/registry/remote-servers) before using it.

## Other assistants and booking platforms

**Gemini:** on November 6, the owner connected the server in Developer Mode on a personal Pro account after accepting Google's consent screen. It appeared in the connector list. Two test chats did not complete and showed no tool call before the owner stopped them. Connection worked; useful execution was not demonstrated. The cause remains unknown.

**ChatGPT:** submission had not started. OpenAI's [submission instructions](https://developers.openai.com/plugins/deploy/submission) and [plugin guidelines](https://developers.openai.com/plugins/plugin-guidelines) require identity or business verification, a plugin ZIP, domain proof returning the exact token as plain text at `/.well-known/openai-apps-challenge` on the requested host, explicit `readOnlyHint`, `destructiveHint` and `openWorldHint` annotations, five success and three refusal or limit tests, an accessible video walkthrough and release notes. Prepare website, support, privacy and terms-of-service URLs. Only one MCP server can be connected per plugin. Descriptions and subtitles must not advertise pricing. External checkout belongs on the business domain. The stated commerce allowance covers physical goods, leaving this lodging use unresolved. These are preparation requirements, not a completed application or a promise of acceptance.

**Google bookings:** [UCP for Lodging](https://developers.google.com/hotels/ucp) offers an interest route. UCP is a commerce protocol; a lodging connector still needs admission to the relevant booking programme. Google's [FAQ](https://developers.google.com/hotels/ucp/faq) requires the payment provider to process its tokens, the payment information passed through that system. The lodging business takes payment at the property and has no online payment step in its booking flow, so it does not meet that requirement today. Its interest applications remain unanswered.

For hotel prices and direct booking links, [Google Hotel Center's owner instructions](https://support.google.com/hotelprices/answer/11946931) direct owners to a connectivity partner while direct integration is unavailable. That partner might be the business's booking engine or property-management provider. This business chose to avoid online travel agencies, limiting its routes. Publishing MCP and booking markup does not remove Google's partner and payment requirements.

## Illustrations for other businesses

These are proposed designs, **not case studies or eligibility findings**. Each starts with public information and leaves a named decision with a person. "Claude + Registry" means prepare those applications and check their current rules.

| Business | Read-only tools | Human step | Documentation and privacy wording to adapt | Route and expectation |
|---|---|---|---|---|
| Dental practice | List services, office hours and public appointment options | Patient submits intake; practice confirms care | "Returns public appointment options. Do not send symptoms or patient records." Explain whether a date query is logged. | Claude + Registry; confirm health-data eligibility before adding patient information. |
| Self-storage | List unit sizes, published rates and available units | Customer signs rental terms and supplies identity details | "A quote does not reserve a unit. Inputs are size and start date." Describe query retention. | Claude + Registry; expect help comparing units, with rental completion on the site. |
| Pickup laundromat | Check service area, turnaround and published price rules | Customer confirms collection address and order | "Checks a postal area without saving a pickup request." State any location logging. | Claude + Registry; service-area answers can lead to a human order. |
| Restaurant | Read menu, opening hours and public table availability | Diner confirms reservation or order | "Availability is a snapshot. This tool creates no reservation." Explain whether party size and time are retained. | Claude + Registry; separately check any booking platform's partner route. |
| Property manager | Search public listings and viewing windows | Applicant supplies documents and signs | "No application or identity documents are accepted here." Document query storage and the separate application page. | Claude + Registry; discovery can end at the application page. |
| Contractor | Read service areas, job categories and estimate windows | Customer approves scope and contract | "This is an estimate request route, not a binding quote." Explain what area and job-type inputs reach the server. | Claude + Registry; expect qualification and a handoff to staff. |

For a dentist, the useful first release might answer "Are you open Saturday?" without touching a patient's file. A storage owner can test different unit names without creating a lease. Both make the documentation simpler by keeping sensitive intake in the existing human process.

A laundromat should test a postal area just outside its route. A restaurant should test a full sitting. A property manager should test a withdrawn listing, and a contractor should test work outside their trade. Each refusal needs a useful next step without suggesting that a booking or contract exists.

## Problems to recognise in your own business

Check the assistant's advice against what you already operate. A generic specification can duplicate completed work or suggest an invalid address. Establish whether the remaining obstacle is a missing feature, missing documentation or the platform's distribution rules.

Test the small form details: the signature date's time zone, whether a tap counts as a signature, and whether a tool exposes fields reserved for the person. Read descriptions alongside real results. A correct total with misleading line items still confuses customers.

Keep the code generators in step with the released server. In the example, regeneration would have removed two fixes until the generator was corrected. Also test the alarm: a scheduled booking check could not open a failure report because that reporting feature was disabled. Monitoring needs a working failure path.

After one release, availability checks briefly timed out from the test runner and then cleared; two other machines could not reproduce it. The cause was not established. Repeat a failed observation and record its scope before assigning a cause.

## Revalidate through the published connector

Approval did not end testing. After publication, customer-style prompts found booking links missing a room-type parameter, a longer-stay note omitting eligible properties, inconsistent currency formatting and "2 night(s)" instead of "2 nights." Calls succeeded and prices were correct. The problems were in what customers read and where the links took them.

One different phone number proved intentional. Record deliberate exceptions so the next reviewer can distinguish them from mistakes.

Keep a written regression checklist: exact inputs and totals, ambiguous names, refusals, accepted date formats and the expected prefilled links. Run it through the listed connector after every release, alongside scripted checks. Compare the quote, form and confirmation email; share formatting code where possible, or prove that all three agree.

This was the owner's maintenance checklist. Check each platform's current update procedure before applying its publication column universally.

| Change | What to release again | Listing work |
|---|---|---|
| Output text and links only | Server | No listing change when tool names, parameters and descriptions stay unchanged |
| Business fact, such as a phone number | Data and pages showing it | No listing change unless the listing also contains that fact |
| Tool description | Server | Update directory and registry descriptions to match; existing connections need not be added again |
| Tool or parameter renamed or removed | Server | Update every affected listing and check clients or saved prompts using the old name |

Bump the server version when behaviour changes and keep Registry entries in step. Check [Claude's update guide](https://claude.com/docs/connectors/building/after-publishing.md). OpenAI checks server changes automatically; every update does not need a new ZIP.

## From working server to watched listing

```text
Server works
  -> Check answers, inputs, annotations and human boundaries
  -> Test every tool as a custom connector
  -> Publish documentation and accurate privacy details
  -> Test the receiving support mailbox
  -> Prove the namespace and publish the Registry entry
  -> Prepare the directory form and reviewer tests
  -> Owner makes declarations and submits
  -> Resolve findings; follow approval through publication
  -> Re-test through the listed connector
  -> Watch failures and repeat checks after each release
```

| Date | Observed result |
|---|---|
| November 5, 2026 | Google hotel panels showed contact-for-rates wording. Lodging and connectivity interest forms were submitted. Directory preparation began. |
| By November 6, 2026 | Claude submission received community approval and was published. The Registry entry was published and active. Custom-connector testing in Claude exercised all four tools with permission requested before each call. |
| November 6, 2026 | Testing after publication found output inconsistencies. Gemini connected, but two chats did not complete. Google applications had no answer; ChatGPT submission had not started. |

## Check your starting point

Use the [Agent Endpoint Inspector](/tools/agent-endpoint-inspector/) to inspect discovery information and the evidence behind endpoint findings. It starts with page reads; protocol checks require the optional handshake on a site you own or have permission to test. It cannot certify directory acceptance, prices or booking completion.

The [WebMCP Readiness Checker](/tools/webmcp-readiness-checker/) helps when the website offers browser tools. The [Agentic Commerce Readiness tool](/tools/agentic-commerce-readiness/) helps review the website's commerce signals. Use their findings to choose checks, then test the real customer journey yourself.

A listing is not customers. An assistant may never recommend the business; a platform can decline an application. Google's booking route remains unavailable to this example on its current partner and payment arrangements. Budget for review and ongoing checks, and read the current requirements before spending on integration work.

## Fact-check notes and sources

The anonymised implementation, form sequence, arithmetic, account tests and outcomes are the author's first-hand observations recorded on November 5 and 6, 2026. Business illustrations are proposed designs. No customer-acquisition result is claimed.

Public references include Claude's [submission guide](https://claude.com/docs/connectors/building/submission.md), [review criteria](https://claude.com/docs/connectors/building/review-criteria.md), [authentication guidance](https://claude.com/docs/connectors/building/authentication) and [custom-connector guide](https://claude.com/docs/connectors/custom), alongside the publishing, verification, Registry, OpenAI and Google pages linked in the relevant sections. Public sources were read on November 6, 2026, between 16:12 and 16:16 UTC. Requirements may change.

## Related reading

- [MCP servers for small business](/blog/mcp-servers-for-small-business/)
- [Making a small business website agent ready](/blog/agent-ready-small-business-website/)
- [Agent readiness beyond llms.txt](/blog/agent-readiness-beyond-llms-txt/)
- [Agent endpoint evidence before verdicts](/blog/agent-endpoint-evidence-before-verdicts/)


---

Canonical HTML: https://jwatte.com/blog/mcp-connector-listing-small-business/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/mcp-connector-listing-small-business.webp