Quick answer: When an MCP server runs through a hosted registry, the operator's view of what the server actually did is limited to whatever logs and metrics the registry chooses to expose, which makes diagnosing a slow tool or a bad response a black-box exercise. A self-hosted server keeps the request, tool invocation, latency, and error logs in your own infrastructure, where they can be correlated with the rest of the system and retained under your own policy. The trade-off is that self-hosting means you run and monitor the process yourself, while the registry gives you easier distribution at the cost of observability and control. If you depend on a registry for a production MCP server and have no first-party logs, the first serious incident becomes a debugging session based on screenshots and vendor status pages rather than the exact request that failed.
Observability is often treated as a later concern when teams first adopt MCP, because the happy path works and the registry makes deployment feel frictionless. In production, though, the questions are inevitable: which tool was called, with what arguments, how long did the upstream take, and was the error generated by the MCP layer or the service behind it? A hosted registry intermediates the transport and may surface aggregate usage or limited logs, but it does not give you the raw, queryable trace of every invocation, and it cannot be joined against your application's request IDs. A self-hosted server emits those logs directly into the sinks you already operate, so an MCP failure is diagnosed with the same tools and correlation model as any other service.
The observability gap is best understood signal by signal rather than as a generic "less control" claim.
| Signal | Hosted registry | Self-hosted server |
|---|---|---|
| Raw invocation logs | Limited or aggregated | Full, queryable |
| Latency per tool | Platform metrics only | Custom histograms |
| Error stack traces | Rarely exposed | Captured directly |
| Correlation IDs | Not joinable | Linked to app traces |
| Retention policy | Vendor-defined | Your own policy |
The correlation row is the practical difference during an incident. When the MCP server logs the same request identifier as the calling application, a single trace follows the action end to end; without it, you reconstruct the timeline from separate, unlinkable systems.
A self-hosted server should log each tool call as a structured event with the tool name, a correlation id, timing, and the outcome, while avoiding secret values in the payload. This makes the logs safe to ship and easy to query.
Scrubbing arguments before logging is a step that is easy to skip and expensive to regret, because tool inputs can contain tokens or personal data. Logging the structure and the outcome while redacting sensitive fields keeps the observability useful without turning the log store into a credential leak.
Beyond logs, expose per-tool latency and error counters so a degraded tool shows up as a metric before users report it, and wire those into the same alerting system as the rest of the platform. Even if you use a registry for discovery or distribution, you can run a self-hosted instance for production traffic and keep the registry entry pointing at it, so you retain the distribution benefit without surrendering the logs.
The contract for the server should document which events and metrics it emits, so the observability surface is a defined interface rather than an ad hoc set of print statements, and a new operator knows what to expect from the logs.
The practical rule is to assume a production MCP server will fail and decide in advance where the evidence of that failure lives. A hosted registry is convenient for distribution but treats detailed invocation data as a platform-controlled, often aggregated view; self-hosting puts raw logs, per-tool latency, and correlation in your own sinks at the cost of running the process. Keep secrets out of the logs, add metrics with alerts, and if you use a registry, point it at a self-hosted instance rather than letting the registry be the only record of what your server did.
They are typically aggregated or limited and cannot be joined to your application's correlation IDs, so you lack the raw per-invocation trace needed to diagnose a specific failed tool call.
No. You can keep a registry entry for discovery while running a self-hosted instance that serves production traffic, retaining the distribution benefit and the first-party logs.
The tool name, request id, duration, and outcome, plus redacted arguments. Avoid raw secrets and personal data in tool inputs, and capture full error detail in your own sink.
Metrics reveal latency and error trends and drive alerts before users notice degradation, while logs answer the detailed why for a specific invocation.
You do. The retention and storage policy follows your own infrastructure and compliance rules rather than a vendor's platform defaults.
This is part of the Powerduck vs Smithery comparison — start there for the full picture of MCP deployment choices.