3 Issues That Remote MCP Developers Should Avoid
Remote MCP servers are only just starting to take off. As more platforms roll out support for the Model Context Protocol (MCP), we’re seeing rapid growth in developer experimentation — and equally, we’re seeing many of the common pitfalls emerge for teams building MCP servers for the first time.
At Portia, we’ve tested a broad range of remote MCP servers — from major providers like Atlassian and Stripe, to emerging integrations like Fulcra, Globalping and Invideo. In the process, we’ve seen a few recurring issues that make MCP servers harder to use, slower to adopt, and more brittle in production.
[For some quick context – Portia is the framework that enables developers to build safe, reliable AI agents. We’d be thrilled to have you check out our SDK and give it a GitHub star!⭐ 🙏]
Here are 3 mistakes we’d recommend every MCP developer avoid.
1. OAuth redirects only work on localhost
Several MCP servers we tested work fine locally, but break when used in real-world staging or production environments. A common cause: OAuth redirect URIs are hardcoded to allow only localhost. While this might be convenient during initial development, it blocks testing in any remote environment.
For example, Intercom and Asana both failed at staging because they rejected valid redirect URIs during authorization flows. This makes it nearly impossible for integrators to properly test your server in their deployment pipelines.
✅ Best practice: Always allow multiple redirect URIs for OAuth clients, including both local and remote environments. Ideally, make this configurable per client.
2. Missing .well-known OAuth metadata
The MCP spec depends on being able to automatically discover OAuth configuration using the .well-known/oauth-authorization-server endpoint. Several servers — including PostHog, Semgrep and Invideo — either failed to serve this file or required tokens to access it, which prevents tool discovery.
Without a valid .well-known file:
- Client libraries can’t automatically configure OAuth.
- MCP agents can’t discover your tool easily.
- Developer experience suffers.
✅ Best practice: Make sure your .well-known/oauth-authorization-server is publicly accessible, standards-compliant, and returns the necessary OAuth metadata.
3. Unreliable server availability
MCP servers are expected to handle dynamic discovery, token exchange, and tool invocation — and this requires a fairly high level of reliability. In our testing, we encountered servers that were down for maintenance (Asana), intermittently unavailable (Plaid, Neon), or failed authorization flows with unhelpful errors (Fulcra).
In an agentic world, unreliability doesn’t just block a single API call — it can break entire task chains and workflows.
✅ Best practice: Invest early in uptime monitoring, clear error messages, and comprehensive OAuth error handling. MCP servers should fail gracefully and predictably.
The Good News: Testing is Easy With Portia
If you’re building a new remote MCP server, testing your implementation doesn’t need to be painful. Portia makes it simple to integrate, validate, and experiment with new MCP servers directly inside your agentic app — often in just 3 clicks.
As the MCP ecosystem matures, we’re excited to help developers ship more reliable, agent-friendly integrations that just work — across staging, production, and every environment in between.
A Bit More About Portia
Portia AI is an open-source framework for building predictable, stateful, authenticated agentic workflows.
We allow developers to have as much or as little oversight as they’d like over their multi-agent deployments and we are obsessively focused on production readiness.
We invite you to play around with our SDK, break things, and tell us how you’re getting on in Discord
