// POST 004 / 029

MCP Marketplace Identity Checklist: What to Verify Before Listing a Server, Tool, or Agent

May 15, 2026 /

MCP makes it easier for AI applications and agents to connect with tools, data sources, and workflows. That is the point of the Model Context Protocol: give AI applications a standard way to reach external systems instead of building a separate integration for every service.

But connection is not identity.

An MCP server can expose tools, resources, prompts, APIs, databases, files, calendars, payment actions, or operational workflows. Before that server is listed in a marketplace, registry, directory, or internal catalog, buyers and operators need a way to inspect who controls it, what it can do, what permissions it needs, and where its trusted record lives outside a single listing page.

That is the purpose of an MCP marketplace identity checklist.

MCP helps agents connect. Identity helps humans, agents, marketplaces, and security teams decide whether that connection should be trusted.

What is an MCP marketplace identity checklist?

An MCP marketplace identity checklist is a practical review process for MCP servers, tools, connectors, and agents before they are published in a marketplace or directory.

The checklist should answer basic questions before an agent or user installs, calls, pays, recommends, or integrates the server:

Who controls this MCP server?
Is this the official endpoint?
What tools, resources, and prompts does it expose?
What actions can modify data or trigger external effects?
What permissions does it need?
What authentication model does it use?
Where are the machine-readable instructions?
Where is the public inspection record?
Is there a human or organization behind it?
If commerce is involved, where are payment and catalog details declared?

This matters because MCP servers are not just documentation pages. According to the official MCP server concepts documentation, MCP servers can expose tools that a model can actively call, resources that provide structured context, and prompts that guide workflows. Some tools can write to databases, call external APIs, modify files, or trigger other logic. That makes identity and permission review operationally important, not cosmetic.

For a broader implementation view, read How to Make Your API Agent-Ready. An MCP server is one part of agent readiness. The identity layer is what helps the server become inspectable across marketplaces, clients, APIs, and the agentic web.

MCP connection vs agent identity

MCP and identity should not be treated as competitors. They solve different problems.

Question	MCP connection answers	Agent identity answers
What can the agent call?	Tools, resources, prompts, schemas, and server capabilities.	Declared capabilities tied to a persistent identity record.
Where does the server live?	Server URL, local transport, package, or remote endpoint.	Stable namespace, verified domain, .AGENT identity, profile, or resolver record.
Who controls it?	May be visible through package metadata, registry namespace, or docs.	Human, organization, vendor, maintainer, or agent operator is explicitly declared.
What permissions are required?	Tool definitions, auth flow, and client approval settings can help.	Permission scope is part of the persistent inspection record.
Can it be trusted outside one marketplace?	A registry or marketplace can make the server discoverable.	A portable identity record makes the server verifiable across clients, directories, and marketplaces.
What happens when money is involved?	The tool may expose a payment, checkout, subscription, or billing action.	The identity record should declare who receives payment, what is being paid for, and where terms can be inspected.

The distinction is simple: MCP helps the agent connect to the server. Identity helps the agent and the marketplace verify the server.

Why marketplaces need identity before listings scale

Marketplaces make discovery easier. They do not automatically make every listing trustworthy.

As MCP marketplaces, registries, and directories grow, the same server may appear in multiple places: an official registry, a third-party marketplace, a GitHub repository, a documentation page, an AI client, an internal enterprise catalog, or a commerce workflow. Without a persistent identity record, reviewers are left comparing scattered signals.

The official MCP Registry helps with namespace authentication and metadata hosting. It also makes clear that downstream aggregators, such as MCP server marketplaces, can add curation, ratings, and additional metadata. The registry focuses on metadata and namespace authentication, while broader security scanning and listing review are handled by package registries, aggregators, and marketplaces.

That leaves a clear opening for identity infrastructure.

A marketplace listing should not be the only source of truth. A serious MCP server, tool, connector, or agent should have a persistent identity that can be checked beyond the marketplace where it was discovered.

For the broader marketplace argument, read Why Agent Marketplaces Need Persistent Identity.

The MCP marketplace identity checklist

Use this checklist before listing an MCP server, tool, connector, or agent in a public marketplace, private registry, internal catalog, or agent directory.

Identity signal	Question to answer	Pass condition
Persistent identity	Does the server have an identity outside one marketplace?	It has a stable namespace, verified domain, .AGENT identity, or persistent profile record.
Controller	Who controls the server?	A human, organization, vendor, maintainer, or agent operator is declared.
Proof of control	Can the controller prove they control the namespace or domain?	DNS, HTTP, GitHub, registry namespace, or another verification method is present.
Official endpoint	Where is the real MCP endpoint?	The server URL, transport type, package source, and version are documented.
Capabilities	What does the server expose?	Tools, resources, prompts, inputs, outputs, and side effects are listed.
Permissions	What access does it need?	Read, write, admin, file, network, user data, and payment permissions are declared.
Approval rules	Which actions require human approval?	Destructive, financial, external, customer-facing, or sensitive actions are marked for approval.
Authentication	How is access controlled?	OAuth, scoped tokens, API keys, or local credentials are documented clearly.
Security posture	Has the server been reviewed for common MCP risks?	Token handling, session handling, prompt injection, SSRF, scope minimization, and local server risk are reviewed.
Machine-readable manifest	Can agents inspect structured metadata?	An agent.json, server.json, manifest, or equivalent machine-readable file is available.
Human-readable instructions	Can developers and operators understand how to use it?	A README, SKILL.md, docs page, or operating guide explains use, limits, and escalation paths.
Directory profile	Is there a public inspection surface?	The server, agent, or operator is listed in Headless Profile Directory or a comparable trusted directory.
Commerce metadata	Can it sell, buy, renew, charge, or recommend purchases?	Payment metadata, merchant identity, catalog data, checkout path, refund policy, and support contact are declared.
Freshness	When was the listing last reviewed?	Version, last updated date, changelog, and maintainer contact are visible.

1. Verify the controller

Every MCP marketplace listing should identify the person, organization, vendor, project, or agent operator responsible for the server.

This is the first trust question. A server that can read files, send messages, access customer data, modify records, or initiate commerce should not be anonymous to the marketplace operator. Even if the server is open source, the listing should make clear who maintains it and where issues should be reported.

At minimum, include:

Controller name
Organization or project
Maintainer contact
Security contact
Support URL
Terms or acceptable use policy
Changelog or release notes

This does not need to be heavy. It needs to be inspectable.

2. Verify the namespace or domain

A marketplace should verify whether the listing is connected to a stable namespace, verified domain, or .AGENT identity.

Why? Because agents and developers need to know whether they are looking at the official server or a copy, proxy, wrapper, fork, or abandoned package.

OpenAI’s MCP guidance recommends choosing official servers hosted by the service providers themselves when possible, rather than relying on third-party proxy servers. That is a practical rule for marketplaces too: prefer official endpoints, verified controllers, and clearly declared namespaces.

This is where Headless Domains fits beside MCP. Headless Domains provides persistent identity infrastructure for agents, tools, and services that need to be discovered, verified, and reached across the agentic web. MCP can describe how to connect. A .AGENT identity can help declare what the server is, who controls it, and where its trusted records live.

3. Verify the endpoint

An MCP marketplace listing should not simply say “connect this server.” It should declare the official endpoint and transport model clearly.

Include:

Remote server URL or local install method
Transport type
Version
Package source, if packaged
Repository URL, if open source
Documentation URL
Expected authentication method
Known client compatibility

For remote servers, endpoint authenticity matters. For local servers, package source and installation integrity matter. For private enterprise servers, internal ownership and access policy matter.

4. Verify tools, resources, and prompts

MCP servers can expose three core types of capabilities: tools, resources, and prompts.

Tools are callable functions that can perform actions.
Resources provide structured access to data or context.
Prompts provide reusable instruction templates or workflows.

Marketplace listings should make these visible before installation. It is not enough to say “CRM MCP server” or “calendar MCP server.” The listing should explain exactly what the server exposes.

For each tool, document:

Tool name
Purpose
Input schema
Output schema
Required permissions
Whether it reads data
Whether it writes data
Whether it triggers external communication
Whether it changes money, account state, records, files, or permissions
Whether user approval is required

For agents, narrow tools are usually safer than vague tools. A tool named create_invoice_draft is easier to review than a tool named execute_action. The name itself should tell the agent and the human reviewer what the action does.

5. Verify permissions before listing

Permissions should be declared before the server reaches users.

Use permission tiers that both developers and marketplace reviewers can understand:

Read-only: Can retrieve data but cannot modify it.
Write-capable: Can create or update records.
Destructive: Can delete, cancel, revoke, or overwrite.
External action: Can send emails, messages, tickets, or notifications.
Admin: Can change settings, permissions, users, or configuration.
Commerce-capable: Can create carts, checkout sessions, invoices, renewals, purchases, refunds, or payment requests.
Sensitive data: Can access personal, financial, business, medical, legal, or confidential records.

The official MCP authorization guide recommends authorization when a server accesses user-specific data, needs auditing, requires user consent, serves enterprise environments, or needs per-user rate limits and tracking. That is a useful baseline for marketplace review.

For payment-enabled or commerce-enabled servers, do not bury permission details in a README. Put them in the listing, the manifest, and the identity record.

6. Verify security posture

MCP security review should be part of the listing process, especially for public marketplaces.

At minimum, review:

Token handling
OAuth scope design
Session handling
Prompt injection exposure
Server-side request forgery risk
Local server compromise risk
Confused deputy risk
Tool poisoning or misleading tool descriptions
Overbroad permissions
Dependency and package risk
Abuse reporting path

The official MCP Security Best Practices documentation identifies MCP-specific risks and mitigations, including token passthrough, SSRF, session hijacking, local server compromise, scope minimization, and other implementation concerns.

Marketplaces do not need to claim that every listed MCP server is risk-free. They do need to show what has been inspected, what permissions are being requested, and where users can verify the server’s identity before connecting it.

7. Require machine-readable metadata

An MCP marketplace listing should include machine-readable metadata that agents and applications can inspect.

Depending on the implementation, this may include:

server.json
agent.json
SKILL.md
llms.txt
OpenAPI specification
MCP endpoint metadata
Permission matrix
Security contact
Payment metadata
Directory profile URL

The machine-readable layer should not replace human documentation. It should make the key facts easier for agents, clients, marketplaces, and security systems to inspect.

For example:

{
  "name": "example-support.agent",
  "controller": {
    "organization": "Example Co",
    "contact": "security@example.com"
  },
  "identity": {
    "namespace": "example-support.agent",
    "profile_url": "https://directory.headlessprofile.com/example-support",
    "verification": ["domain-control", "dns"]
  },
  "mcp": {
    "server_url": "https://mcp.example.com/mcp",
    "transport": "streamable-http",
    "tools": ["lookup_order", "create_return_label"],
    "resources": ["policy://returns", "catalog://products"],
    "prompts": ["resolve_customer_issue"]
  },
  "permissions": {
    "reads_user_data": true,
    "writes_records": true,
    "takes_payments": false,
    "requires_approval_for": ["refund", "account_change"]
  }
}

The exact schema may vary. The principle should not: identity, endpoint, capabilities, permissions, and controller data should be explicit.

8. Add a public inspection surface

A marketplace listing is useful, but it should not be the only place where identity is inspected.

Use a public profile or directory record for the MCP server, agent, tool, or operator. This lets buyers, agents, developers, and marketplace reviewers verify the listing across contexts.

Headless Profile Directory can serve as the public inspection surface for agentic identities. A profile can point to the agent or server’s identity record, declared capabilities, trusted endpoints, support links, marketplace listings, and related metadata.

This is especially useful when the same MCP server appears in several places:

An MCP registry
A third-party MCP marketplace
A developer documentation site
An enterprise internal catalog
An AI client integration page
A commerce workflow
A partner directory

Discovery spreads. Identity should remain stable.

9. Add commerce metadata when money is involved

If an MCP server can sell, buy, renew, charge, refund, create checkout sessions, recommend purchases, or expose product data, identity review needs a commerce layer.

The listing should declare:

Merchant or seller identity
Catalog source
Product or service data
Pricing
Currency
Availability
Checkout path
Payment metadata
Refund and cancellation policy
Support contact
Approval thresholds
Dispute path

This is where Build My Online Store can support agent-readable merchant catalogs. When agents are involved in product discovery, catalog comparison, cart creation, or checkout routing, merchants need structured data that can be read before an action is taken.

Payment rails answer whether value can move. Identity answers who is requesting payment, who is receiving it, what is being paid for, and where that relationship can be verified later.

10. Decide whether the listing should be public, private, or internal

Not every MCP server belongs in a public marketplace.

Some servers should stay private or internal because they expose sensitive systems, proprietary workflows, private data, admin actions, or enterprise-only resources. Others may be safe for public listing because they are read-only, narrow, well-documented, and tied to a verified public identity.

Before listing, classify the server:

Public: Safe for broad discovery, with reviewed metadata and limited risk.
Partner-only: Available to approved partners or authenticated users.
Private: Used by a specific organization or account only.
Internal: Used inside a company, not intended for public discovery.
Experimental: Not production-ready and clearly labeled as such.

The classification should appear in the listing and the identity record.

Implementation recommendations for marketplace operators

If you operate an MCP marketplace, registry, catalog, or directory, treat identity as part of listing quality.

Add an identity block to every listing. Include controller, verified namespace, official endpoint, maintainer, support contact, and profile URL.
Require capability declarations. Tools, resources, prompts, side effects, and permissions should be visible before installation.
Use permission badges. Mark read-only, write-capable, destructive, admin, payment-capable, commerce-capable, and sensitive-data servers.
Prefer official servers where possible. When a third-party proxy exists, label it clearly and disclose who operates it.
Require approval rules for sensitive actions. Money movement, external messaging, deletion, account changes, and customer-facing actions should not be hidden.
Add security review fields. Include token handling, auth model, session model, scope minimization, and known risk notes.
Require a public inspection URL. Use a directory or identity profile so the server can be verified outside one marketplace.
Require commerce metadata when relevant. If the server touches checkout, payments, pricing, or merchant catalogs, expose the commercial rules clearly.

Implementation recommendations for developers

If you are building an MCP server, design it for inspection before distribution.

Start with the identity record. Define the server name, controller, namespace, support contact, and official endpoint.
Use clear tool names. Prefer narrow actions like search_products, draft_invoice, or lookup_order_status over generic actions like execute.
Separate read and write scopes. Do not give agents broad permissions when a narrow permission will work.
Document approval requirements. Make it clear which actions require user confirmation.
Publish machine-readable metadata. Use server metadata, manifests, SKILL.md, llms.txt, OpenAPI, or equivalent files.
Use OAuth or scoped credentials when needed. Especially for user data, enterprise use, auditability, and consent-based access.
Build for revocation and auditability. Users and operators should be able to see what happened and revoke access.
List only when ready. A server that can modify data, trigger transactions, or touch sensitive information should not be listed before its identity and permissions are clear.

For a related pre-listing checklist focused on agents themselves, read Before You List Your Agent on a Marketplace: The Identity Checklist.

Where Headless Domains fits

Headless Domains is not a replacement for MCP. It is the persistent identity layer that can sit beside MCP tooling.

MCP helps the agent connect to tools and resources. Headless Domains helps the agent, server, tool, or operator expose a persistent identity record that can be discovered, verified, and reached across the agentic web.

A practical Headless Domains identity record can point to:

.AGENT identity
agent.json
SKILL.md
MCP endpoint
OpenAPI spec
Permission matrix
Payment metadata
Support contact
Security contact
Headless Profile Directory listing
Commerce catalog, when relevant

That gives marketplaces and developers a cleaner model:

MCP for connection. Headless Domains for persistent identity. Headless Profile Directory for inspection. Build My Online Store for agent-readable commerce when merchants are involved.

FAQ

What is an MCP marketplace identity checklist?

An MCP marketplace identity checklist is a review framework for verifying the identity, controller, endpoint, capabilities, permissions, security posture, manifests, and public inspection record of an MCP server before it is listed in a marketplace or directory.

Does MCP solve identity by itself?

MCP standardizes how AI applications connect to external tools, resources, and workflows. It can support authorization, metadata, and structured tool definitions, but marketplaces still need persistent identity records that answer who controls a server, what it represents, and where its trusted public record lives.

What should an MCP marketplace verify before listing a server?

At minimum, verify the controller, namespace or domain control, official endpoint, capabilities, permission scope, authentication model, approval rules, machine-readable metadata, security contact, and public inspection profile.

Why does an MCP server need a persistent identity?

A persistent identity gives the server a stable source of truth outside one marketplace. It helps agents, developers, buyers, and operators verify whether the server is official, who controls it, what it can do, and where its trusted records live.

How does Headless Domains relate to MCP?

Headless Domains can sit beside MCP as a persistent identity layer. MCP helps agents connect to tools. Headless Domains helps agents, tools, and MCP servers expose stable, verifiable records that can be discovered and inspected across the agentic web.

What is the difference between an MCP registry and Headless Profile Directory?

An MCP registry helps publish and discover MCP server metadata. Headless Profile Directory can act as a public inspection surface for agentic identities, including profiles, manifests, trusted endpoints, support links, and verification data.

Should every MCP server have a .AGENT identity?

Not every experimental or private server needs one. Public marketplace listings, commercial tools, payment-capable workflows, agent-operated services, and servers representing a business or person are stronger candidates for a persistent .AGENT identity.

What extra checks are needed for commerce MCP servers?

Commerce-capable MCP servers should declare merchant identity, catalog source, product data, pricing, availability, checkout path, payment metadata, refund policy, support contact, and approval requirements before they are listed or called by agents.

Final takeaway

MCP makes tool access more standardized. Marketplaces make MCP servers easier to discover. But trust requires a separate inspection layer.

Before an MCP server, tool, or agent is listed, verify who controls it, what it exposes, what permissions it needs, how it handles sensitive actions, and where its persistent identity record lives.

Connection is the start. Identity is what makes the connection inspectable.

Give your MCP server or agent a persistent identity with Headless Domains, then make it inspectable through Headless Profile Directory. If commerce is involved, use Build My Online Store to support agent-readable catalogs, policies, and checkout paths.

[← ALL POSTS] [GET YOUR .AGENT →]