The decision
Build discovery, connection setup and tool execution as distinct stages. A catalog card helps users choose a server; your product must still own authorization, tenant isolation, persistence and the execution policy.
Let users inspect a server before connecting
Show the provider, publisher evidence, supported transport and setup requirements on each card. Distinguish an official implementation from an unverified registry listing. Preserve the registry source and review date so users can judge how the listing was established.
Selecting a card should open a server detail view with the required fields already identified. Do not bury connection settings after a failed health check. If a requirement is unknown, link to the publisher instructions instead of inventing a default.
Put credentials and identity at the application boundary
Resolve the signed-in user and tenant on your backend. Decide whether a connection belongs to one user or a shared workspace, and enforce that rule when loading it. Complete the server’s documented authorization flow before requesting tools.
Store credentials using your host application’s secret-management design, and keep them out of client-visible catalog data. Revocation, deletion and reconnect are part of the feature, not optional administration tasks. Treat a pasted endpoint as untrusted input and apply your network-access policy before contacting it.
Use MCP Connect for reusable connection plumbing
The published @apideck/mcp-connect package loads tools from stored connections, namespaces tool names and dispatches calls back to the selected server. Its persistence, OAuth and encryption seams are supplied by the host application. It is infrastructure for a marketplace experience, not a complete hosted marketplace UI.
The package’s ConnectionStore contract distinguishes tenant and per-user visibility. Implement that contract against your datastore and test it with two tenants and two users before using shared workspace connections. Pin the package version and check its README before adopting an example.
Show what connected actually means
After authorization, list tools and display the useful subset. Let users see which account is connected and what operations are available. A successful tool-list request should not be shown as proof that every tool will execute successfully.
Apply approval and logging rules at execution time. Record bounded operational metadata such as outcome, duration and server identity according to your privacy policy, rather than indiscriminately recording credentials and tool payloads. Test disconnect during a request, stale tool catalogs and a server that becomes unavailable. End with an actionable recovery state.
Your next step
Use these checks in a bounded proof of integration.
- Keep discovery separate from authorization and execution.
- Define per-user versus workspace ownership.
- Test tenant isolation and revoke access.
- Distinguish configured, connected and successfully executed.
Profiles to inspect: Appwrite · Parallel · Pydantic Logfire
Sources and editorial scope
Product statements refer to the publisher sources below, reviewed on 2026-10-21. The decision criteria and checklists are API Tracker’s editorial analysis. They are not compatibility certifications or benchmark results. API Tracker is built by Apideck.
Suggest a correction →