# MCP connector listing kit for small and medium businesses

Version: November 6, 2026. Public references checked on that date between 16:12 and 16:16 UTC.
Companion guide: https://jwatte.com/blog/mcp-connector-listing-small-business/

Use this as a worksheet with your web person. Replace every example.com address and every bracketed blank. The examples describe proposed designs, not a completed application for your business. Recheck each platform's current instructions before submitting. Never copy a privacy promise until you have checked the code and providers behind it.

## 1. Assign responsibility and define the boundary

- Business display name: [name]
- Person responsible for listing and support: [owner or role]
- Person responsible for server changes: [role]
- Assistant and directory to apply to: [platform]
- Public endpoint: https://example.com/mcp
- Public documentation: https://example.com/connect
- Privacy section: https://example.com/privacy#connector
- Support page: https://example.com/support
- Terms page, where required: https://example.com/terms
- Server version: [version]
- Last customer-style test: [date and result]

Write the promise in one sentence: "This connector helps a customer [read public information or compare options]. The person must [confirm, sign, send or pay] on [business page]."

An MCP tool is a named function an assistant can call. A read-only tool returns information without saving a request, holding inventory or changing a record. A directory listing helps someone find the connector; it does not establish demand or permission to sell through a platform.

## 2. Prepare the additional elements

- [ ] Public documentation explains connection, inputs, examples, limits and help.
- [ ] Privacy wording matches input handling, logs, retention and providers.
- [ ] The support mailbox on the business domain receives a test message.
- [ ] The server has a recognisable human title matching its listing.
- [ ] Tool names, titles and descriptions match actual behaviour.
- [ ] Inputs accept documented ordinary forms; ambiguous names request clarification.
- [ ] Reading and writing use separate tools. Public information tools ask only for needed inputs.
- [ ] Every tool has the effect annotations required by the destination.
- [ ] Descriptions and printed line items agree with the calculation.
- [ ] A quote, the website form and confirmation agree on totals and formatting.
- [ ] Server validation enforces every required agreement, signature and confirmation.
- [ ] Browser tools explicitly list permitted fields and exclude human-only and anti-spam fields.
- [ ] Every tool has been tested as a custom connector in the intended assistant.
- [ ] Reviewer instructions and example prompts are complete.
- [ ] The owner has read each declaration and is ready to make it personally.

Annotations describe effects. `readOnlyHint` says whether the tool only reads; `destructiveHint` describes potential destructive changes; `openWorldHint` describes interaction beyond a closed set of resources. Apply the destination's definitions to the actual implementation. Do not infer one platform's requirements from another's labels.

For example, OpenAI distinguishes additive writes from destructive writes, while Claude's review checklist asks for `destructiveHint: true` for tools that modify or delete data. A tool that stores a draft is a write even when it sends nothing to a customer.

## 3. Prepare Claude's ten form steps

Read https://claude.com/docs/directory/publish and https://claude.com/docs/connectors/building/submission.md . Choose the submitting account or organisation carefully because it owns the listing. Directory submission requires a paid plan; personal testing and public listing have different eligibility rules.

Test as a custom connector first. Open https://claude.ai/directory/manage and select Submit new, then MCP connector. Current documentation permits a server URL or a connector already added to the account. The worked example used the existing connector.

| Step | Prepare and check |
|---|---|
| 1. Connection | Endpoint URL, custom connection if already added, expected tool and resource counts, and sign-in method. Compare the portal's detected results with the server. |
| 2. Tools | Title and description for each tool; the required read-only or destructive annotation; separate tools for reading and writing. Correct the server before continuing if the detected definitions are wrong. |
| 3. Listing | Display name, carefully chosen slug, one-liner up to 200 characters, description up to 2,000, one to five categories, author details, icon and public documentation, support and privacy links. Current docs lock the slug after publication. |
| 4. Use cases | Prepare up to three examples, as the observed form allowed, each with a prompt, prerequisites and read/write classification. Recheck the current form's limit. |
| 5. Company | Company name, public website and an accountable primary contact. |
| 6. Authentication | Check what was detected. Public-data tools may require no sign-in. Explain setup and test access if sign-in is needed. |
| 7. Data handling | State whose API the connector calls, whether it handles personal health data and whether results include sponsored content. Do not guess eligibility for an API you do not control. |
| 8. Test and launch | Instructions, required test access, prompts and expected results. Run every tool before making the self-test acknowledgement. |
| 9. Compliance | Have the owner review the seven declarations below against evidence. |
| 10. Review and submit | Review the whole listing, submit and record the status. Follow the status card: an Approved submission may still need Publish; some Community listings are automatic. Verify visibility afterwards. |

Community and Verified are different statuses. Community screening does not establish a security audit or a performance guarantee. Check https://claude.com/docs/connectors/verification and https://claude.com/docs/directory/submission-status.md .

### Declarations belong to the person submitting

Prepare evidence for each item. These are not boxes an automated helper should tick on the owner's behalf.

- [ ] I have read the directory guidelines.
- [ ] The connector calls the business's own first-party APIs, as the form requires.
- [ ] It does not transfer money or other financial assets.
- [ ] It does not use AI models to generate images, video or audio.
- [ ] Tool descriptions contain no hidden text or instructions about model behaviour, other tools or external instruction sources.
- [ ] It does not collect conversation data beyond what is needed.
- [ ] Public documentation will be live by the publication date.

If any statement does not fit the implementation, stop and check the current rules. The broader review guidance discusses permitted partner APIs; the owner must answer the actual form accurately. Keep consent screens with the owner too.

## 4. Publish the official MCP Registry entry

Read these pages before using the publisher:

- https://modelcontextprotocol.io/registry/quickstart
- https://modelcontextprotocol.io/registry/remote-servers
- https://modelcontextprotocol.io/registry/authentication
- https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json

The Registry is in preview. Publication and an assistant's directory review are separate processes.

- [ ] Choose the publishing namespace. A namespace identifies who controls the entry, such as the `com.example` part of `com.example/booking-info`.
- [ ] Prepare server.json. The following is an illustrative shape; replace the domain, version, title and description before validating. Title and websiteUrl are supported optional fields. The cited schema limits description to 100 characters.

```json
{
  "name": "com.example/booking-info",
  "title": "Example Business Information",
  "description": "Read public availability and service information from Example Business.",
  "version": "1.0.0",
  "websiteUrl": "https://example.com",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://example.com/mcp"
    }
  ]
}
```

- [ ] Prove control with the documented GitHub or domain method. DNS proof for a reverse-domain namespace uses a TXT record shaped like `v=MCPv1; k=ed25519; p=PUBLICKEY`. Use your generated public key; never publish the private signing key.
- [ ] Install the publisher through the official quickstart. Run its validation command against the completed file, following the installed version's help.
- [ ] Log in using the chosen proof method, then publish. The observed publisher supported validate, login and publish.
- [ ] Read the published entry. Check status, endpoint and version against the intended server.
- [ ] Record who owns signing credentials and where recovery instructions are held securely. Keep secrets out of the documentation and listing.

`streamable-http` identifies the remote connection type. Namespace proof establishes the publisher's identity; it is separate from customer sign-in to the connector.

## 5. Write reviewer instructions and test prompts

Reviewer setup:

"Connect to https://example.com/mcp using [connection method]. [No sign-in is needed for public information / obtain the supplied test account through the review process]. Run the following prompts. Expected results are checked against [business source and date]. None of the read-only tests should create a booking or record."

For each tool record:

| Item | Fill in |
|---|---|
| Tool name and purpose | [name; what it returns] |
| Exact prompt | [customer's natural wording] |
| Required inputs | [fields and accepted formats] |
| Expected answer | [known result or calculation] |
| Expected link | [destination and prefilled choices] |
| Expected refusal | [unsupported request and useful next step] |
| Record-change check | [how you verify that nothing was held or saved] |

Suggested patterns to adapt:

1. "What [options] are available for [dates or service area]?"
2. "Quote [one specific option] for [quantity or length]. Explain the total."
3. "Use [a valid short name]." Repeat with an ambiguous name and check clarification.
4. "Can you complete [the signature, agreement or confirmation] for me?" Check the human boundary.
5. "Find [an unavailable option or an area outside the service boundary]." Check the refusal.
6. Follow the returned link and check that every permitted choice is filled correctly. The person completes the final action.

For prices, keep the actual calculation basis. In the lodging illustration, rounding $250 divided by seven to $35.71 and then multiplying by seven gives $249.97; rounding once after multiplying gives $250.00. Tests need both totals and the printed explanation.

Use your own published price table and a controlled test setup. Do not create live orders merely to test a read-only tool. If a separate transaction test is needed, define its authorisation, test record and cancellation procedure with the owner.

## 6. Public documentation page outline

Title: [Business display name] connector

1. **Purpose:** "Use this connector to [public information tasks]."
2. **Connection:** endpoint https://example.com/mcp; supported connection method [method]; sign-in requirements [requirements].
3. **Setup:** numbered instructions in the intended assistant; prerequisites [prerequisites].
4. **Tools:** name, human title, required inputs, accepted formats, example prompt, sample result and effect on records for each tool.
5. **Limits:** "It does not [make a reservation, sign, pay, submit an application or other actual exclusions]."
6. **Human handoff:** "Open [business page], review [details] and personally complete [action]."
7. **Data:** summary of the privacy section, with a link to https://example.com/privacy#connector .
8. **Accuracy:** source of rates or availability [source]; update timing [verified timing]; handling of expired results [behaviour].
9. **Support:** https://example.com/support and a monitored domain mailbox, with a response promise only if the business can keep it.
10. **Changes:** current version [version], last checked [date], and material behaviour changes [notes].

## 7. Connector privacy section outline

Have the person who understands the code complete this. It is a drafting worksheet, not a substitute for reviewing your actual data practices.

"When you use [connector], our server receives [exact inputs]. It [does/does not] require an account. It receives [conversation content, if any; verify]. We use these inputs to [purpose]."

"On successful requests we record [fields or verified absence of logging]. On failed requests we record [fields]. We retain these records for [verified duration and deletion process]. Our service providers [providers and roles] process [request information]. Their applicable policies are [public links]."

"The connector [does/does not] create or save [drafts, bookings or customer records]. To complete [transaction], you go to [business page], where [separate data handling] applies. Questions and data requests can be sent through [support route]."

Verify each blank against:

- Request validation and tool inputs.
- Successful and failed response paths.
- Application logs and hosting-provider logging.
- Monitoring, analytics and error reporting.
- Retention settings and deletion behaviour.
- Any onward service or API.

Record the check date and code version. Review again whenever an input, log line or provider changes. A public, unauthenticated tool still needs accurate data-handling disclosures.

## 8. Other platform preparation

**ChatGPT:** read https://developers.openai.com/plugins/deploy/submission and https://developers.openai.com/plugins/plugin-guidelines . Prepare verified individual or business identity, plugin ZIP, one connected MCP server, exact domain challenge token, effect annotations, five positive and three negative cases, accessible video walkthrough, release notes, and HTTPS website, support, privacy and terms URLs. Positive cases show expected success; negative cases show correct refusal or limits. Recheck the physical-goods commerce restriction before planning a service or lodging transaction. For domain proof, use the host shown in the portal and serve only its exact plain-text token at `https://example.com/.well-known/openai-apps-challenge`, replacing the example host. This worksheet does not establish eligibility.

**Gemini:** the observed personal Pro account could connect a custom server through Developer Mode and consent. Two chats did not complete. Test actual tool execution yourself before promising support.

**Google lodging:** read https://developers.google.com/hotels/ucp , https://developers.google.com/hotels/ucp/faq and https://support.google.com/hotelprices/answer/11946931 . The interest route, rate-distribution partner route and payment compatibility are separate checks. A submitted form does not establish acceptance. Use a business-domain contact address where required.

## 9. Revalidate after publication and every release

- [ ] Connect through the public listing and repeat the customer prompts.
- [ ] Check exact totals and printed line items, including boundary lengths or quantities.
- [ ] Check accepted names and input formats, unavailable options and refusals.
- [ ] Follow links and verify every prefilled value.
- [ ] Compare currency, plural wording and contact details across tools and pages.
- [ ] Document intentional exceptions, such as a different phone number at one location.
- [ ] Confirm generators reproduce the intended released behaviour.
- [ ] Test that a monitoring failure actually reaches the responsible person.
- [ ] Repeat unexplained failures and record where they occurred before naming a cause.
- [ ] Bump the server version for behaviour changes and keep Registry records in step.

Use this practical change checklist, then check the platform's actual publication process:

| Change | Release | Listing check |
|---|---|---|
| Output text or links | Server | No listing edit when definitions and listing details are unchanged |
| Business fact | Data and every page showing it | Update any listing that repeats that fact |
| Tool description | Server | Review and update affected directory or Registry details; existing connections need not be added again |
| Renamed or removed tool or parameter | Server | Update affected listings and test old clients and saved prompts |

Claude's update guide: https://claude.com/docs/connectors/building/after-publishing.md . OpenAI's submission guide describes automatic checks for server changes and separate package updates. Do not assume every update requires a new application.

## 10. Check the starting point

- Agent Endpoint Inspector: https://jwatte.com/tools/agent-endpoint-inspector/ . Inspect discovery information; enable protocol checks only for an authorised target. It never calls tools or proves booking completion.
- WebMCP Readiness Checker: https://jwatte.com/tools/webmcp-readiness-checker/ . Review browser-tool declarations, then exercise the actual permitted fields.
- Agentic Commerce Readiness: https://jwatte.com/tools/agentic-commerce-readiness/ . Review website signals separately from platform acceptance.

Done means the listing is visible, the owner has repeated the customer tests, and someone receives failures. It does not mean that the directory will send customers or that every assistant can complete a transaction.