An agent can show a connection card for a custom MCP server, including one outside the standard app catalog. The card opens Clero’s setup flow so you can review the server and provide authorization without placing credentials in chat.
Use this when an external service exposes a public Streamable HTTP MCP endpoint over HTTPS. This guide covers that connection route, rather than a local stdio process. The connection does not by itself establish which tools an agent may use or authorize every action those tools support.
The connection-request prerequisites also apply: current source requires an accepted organization admin/champion with integration-management permission and a suitably enabled agent.
Prepare the right endpoint
You need the server’s actual HTTPS MCP endpoint, its owner, and the authentication method it expects. A product’s homepage is not necessarily its MCP endpoint. Use the service’s official setup documentation or information supplied by the server owner.
The agent can search the available connection catalog and look up relevant setup information. It should not invent a URL, client identifier, token, or header value to complete a card. If the endpoint is missing, supply or confirm it before proceeding. A catalog name alone does not always provide the endpoint required for custom setup.
Ask the agent for a custom connection card
A bounded request is:
I want to use the custom MCP server from [service or server owner] for [task]. Its documented HTTPS MCP endpoint is [endpoint]. Show me a connection card and explain the authentication it requires. I will enter credentials in the setup form. Do not run server tools yet.
If you do not know the endpoint:
Find the official MCP setup instructions for [service]. Identify its supported endpoint and authentication method, then show me the connection card if the required details are available. Ask me about anything you cannot verify.
The agent can prepare the request; you still review the destination and decide whether to authorize it. A card does not prove that the server is trustworthy or that access has been granted.
Review the card and connection settings
- Check the card’s connection name, reason, endpoint when shown, and authentication label.
- Select Connect.
- Inspect the prefilled setup form. Expand Review connection settings to check Endpoint URL and the optional Connection Name, or to correct the configuration.
- Confirm that the endpoint and authentication match the intended server.
- For OAuth, select Continue to Provider and review the provider flow. For manual authentication, complete the relevant fields and select Connect only when ready to submit the configuration.
- Return to the conversation and verify the saved connection and needed tool access.
Do not approve a different server just because its name resembles the service you intended to use. If the destination is wrong or the request is unnecessary, select Cancel on the card for an unnecessary request, or ask the agent to correct the configuration. Closing the setup window alone does not resolve the request.
Choose the authentication the server requires
The form provides an OAuth flow and manual authentication through Auth Type. Its supported approaches are:
| Choice | What you provide or review |
|---|---|
| OAuth | The server’s sign-in and consent flow; check the account and access before approving |
| None | No authentication credentials; use only when the server is intentionally configured for unauthenticated access |
| Bearer token | The required token in Bearer Token |
| Custom header | The required Auth Header Name and Header Value |
“None” is not a way to bypass authentication on a protected server. Use the method documented by its owner. A bearer token or custom header can carry powerful access; use the intended credential and scope rather than a broadly privileged one by default.
Never put tokens, passwords, client secrets, or secret header values in the conversation, a screenshot, or an example document. The agent can help identify which field is needed without receiving its secret value in chat.
Review advanced settings only when needed
The current form can expose Protocol Version, External ID, and Extra Headers. Advanced OAuth settings includes Client ID, Client Secret, Authorization Server URL, Resource Metadata URL, Authorize URL, Token URL, and Scopes. Populate these only when the server’s documented setup requires them; do not guess values or copy an unrelated app’s OAuth configuration.
Optional Context Parameters forward selected context with calls to the server. Review what you intend to share before enabling them. Where offered, Test connection before saving performs tool discovery and contacts the server; it is not only a local form check. Its initial setting can depend on the preset. A connection saved without a successful test is not proof that the intended operation works.
Return and verify the useful capability
After setup, the card updates and the agent can continue once the response’s connection requests and questions are resolved. You can also ask it to check whether the particular tool you need is available. Start with a bounded read-only operation when the server supports one:
Verify that this MCP connection is ready and that you have the capability needed for [specific read-only task]. Report any missing tool permission. Do not create, change, publish, or delete anything.
Clero confirms the saved connection, but the agent may still need access to that connection’s tools. A successful custom MCP connection creates a connection-specific tool option; it does not automatically grant that option to the requesting agent. See Capabilities. Discovering a tool does not mean you requested every action it can perform.
Fix the specific setup problem
- No card: Ask for the exact service or custom MCP connection and confirm that a real HTTPS endpoint is available.
- Wrong settings: Review the endpoint and auth choice before submitting; do not fix a bad URL by adding broader credentials.
- Setup failed: Read the error. The card can offer Try again after failure; retry the corrected setup rather than repeating an uncertain external operation.
- Connected but tools unavailable: Ask which tool grant or capability is missing. A new connection alone is not an answer to every permission error.
- Connection needs reconnection or the account changed: Ask for the connection card again for that connection. Source-backed reconnect can reuse its saved endpoint, name, and other non-secret settings, but never prefills secrets. Review the identity and requested access; enter any replacement credential only in the setup form. A missing saved endpoint must be corrected rather than guessed.
Read Connect apps through an agent for the common card-to-authorization workflow and Connection troubleshooting for the diagnostic checklist.
What the documentation verified
The card/form contract and authentication options are source-backed. No custom card was rendered in the isolated demo: its requester/agent did not meet the connection-request prerequisites, and no actual endpoint was supplied. No custom MCP server was connected, no credentials were submitted, and no server tool was executed for this guide. Exact deployed behavior can depend on the server’s authentication and available capabilities.