MCP server listing requirements

​

Listing requirements

​

Security

• mcpUrl format: the mcpUrl value must use HTTPS, must not embed secrets or credentials (including no token-in-URL or equivalent anti-patterns), and must point to a spec-compliant MCP server that supports SSE and/or HTTP streamable transport.
• Scopes alignment: the scopes and permissions implied by the MCP component must align with the parent app’s required scopes configuration.
• End-to-end access: the MCP server must support successful authenticated access to the third-party platform it wraps, including token refresh, and must expose at least one tool invocable end-to-end with real data.
• Security risk: the MCP server must present low security risk for data exfiltration and tool poisoning, with no unresolved critical or high vulnerabilities at the time of review.
• Server ownership: the mcpUrl must resolve to a verified, official server owned by or explicitly delegated to the named platform. Third-party connectors (for example, a partner building a connector to another company’s MCP server) are not permitted at this time.

​

Privacy & compliance

• Required URLs: websiteUrl and privacyPolicyUrl must be present, valid, and clearly associated with the MCP server’s owning platform.
• Sensitive data: apps approved for access to sensitive data scopes may not include an MCP component.
• EU AI Act compliance: MCP components must not support “Unacceptable risk” or “High risk” AI use cases under the EU AI Act. This is the same standard applied to agent tools.

​

Reliability & testing

• Demo video: you must provide a short demo video showing MCP component configuration, the connection test flow, and at least one successful tool invocation within Breeze.

​

Usability & labeling

• Component name: the component name must clearly identify the external platform and integration purpose. For example, “Acme MCP” is acceptable; “MCP Server” is not.
• Component description: the description must be clear, succinct, and non-marketing. Explain what the integration enables in HubSpot rather than restating the name.
• Ownership clarity: the owning party must be clearly inferable from the component metadata. The component must not suggest it is HubSpot-built when it is partner-built.

​

MCP listing fields

​

mcpUseCases

• Describe in plain-language a concrete front-office use case, understandable to end users (e.g., “Summarize post-call notes from <YourPlatform> into HubSpot records”).
• Avoid internal jargon, bare feature names (e.g., just “CRM sync”), or purely marketing slogans. They should describe what a customer can accomplish, not only how the integration works.
• Not describe clearly prohibited or high-risk AI use cases (e.g., social scoring, biometric surveillance, employment decisioning) and must not position processing of HubSpot-classified sensitive data as the primary purpose of the MCP integration.
• Be truthful and directionally accurate. They may summarize multiple MCP tools at a high level but cannot materially misrepresent what the MCP server can do (e.g., claiming automation or data access that does not exist).

​

mcpTools

• name: must be a machine-style identifier with no spaces, matching the MCP server function name exactly (e.g., fetch_tasks, not “Fetch Tasks”).
• description: must be clear, concise, and in plain language describe what the tool does from a HubSpot user perspective (e.g., “Get a list of Supered tasks associated with a HubSpot contact”). It must not restate the name or read as marketing copy. In addition, the description must not advertise or normalize clearly disallowed high-risk AI use cases or encourage direct handling of sensitive data as a primary behavior.
• accessType: must accurately reflect what the tool can do with HubSpot or external data: any tool that can create, update, or delete data must be marked "write". "readOnly" is reserved for tools that never mutate data. When in doubt, use "write".

​

Submitting your MCP component for approval