.jpg)
September 27, 2025
This week, we hosted a live workshop with Wojciech Błaszak, CEO and co-founder of Golf, YC X25, on how companies can deploy MCP servers in production and build agents they can trust. Our discussion covered adoption trends, security challenges, best practices for server design, and what is next for the MCP ecosystem.
MCP adoption has grown quickly, with two main categories of servers emerging:
Local servers, loved by developers but risky for enterprises because they often require admin credentials and API keys in plaintext.
Remote servers, which are still early but represent the long-term direction. Enterprises are starting to expose APIs through hosted MCP servers, similar to how APIs themselves became standard.
The protocol itself is less than a year old, but enterprises are already experimenting. The most successful servers are not thin wrappers of OpenAPI specs. They are carefully scoped with 10–15 tools and built around clear use cases.
Barriers today are less about features and more about friction:
Security: Authentication, authorization, and audit trails are still patchy. OAuth is supported, but API key handling is unsolved. Enterprises hesitate to take on that risk.
Prompt injection attacks: These are the new SQL injection, and defenses are still emerging. Middleware and audit trails are critical.
Shallow implementations: Too many servers are built as wrappers without real production-readiness, which erodes trust.
When asked about a “quick win” tactic for deploying MCP servers, Wojciech’s advice was clear: do not blindly convert OpenAPI specs to MCP. Instead, narrow the scope, focus on real use cases, and design servers with agent experience in mind. Converters are fine for prototypes, but they will not make it to production.
When asked if there is a standard framework for moving from APIs to MCP, Wojciech emphasized three principles:
Start with read-only tools. Write operations bring too much risk, especially in enterprise settings.
Reduce the number of endpoints. Cutting down by around 30 percent helps avoid overwhelming agents.
Involve beta users early. The most successful MCP launches he has seen were when teams released a first version of their server to a small group of customers, gathered feedback on how it was actually used, and then adjusted the tools and capabilities based on that feedback.
Security challenges differ depending on context:
B2B: The biggest risk is supply chain attacks from local servers downloaded off GitHub without inspection. Enterprises should stick with remote servers and first-party providers.
Both B2B and B2C: Guardrails are essential to prevent PII leaks. Enterprises must own the data flow with middleware, audit trails, and scanning layers.
Prompt injections: Natural-language attacks will only grow more creative. Guardrails and monitoring are non-negotiable.
While most MCP clients today live in IDEs or tools like GPT and Claude, three emerging patterns are taking shape:
Internal clients: Enterprises building MCP servers and clients for their own use.
External clients: Exposing servers to third-party platforms.
Third-party adoption: Vendors building agents that integrate with others’ MCP servers.
The first category dominates today, as enterprises prefer to own both sides for security and reliability.
Performance trade-offs are real. Wojciech recommended capping servers at 30–40 tools across multiple servers to preserve reliability. Gateways can help consolidate tool choices and manage context windows, though they add latency.
Longer-term, orchestration may not scale well. Chaining multiple agents reduces accuracy, and Wojciech argued the future may lean toward simpler, single-agent systems rather than complex hierarchies.
Scope matters. Narrow, use-case-driven servers outperform thin OpenAPI wrappers.
Security is the bottleneck. Audit trails, auth, and defenses against prompt injection must come first.
Adoption is internal-first. Enterprises are starting with internal clients before exposing servers externally.
The ceiling today. Around 30–40 tools per server, with gateways helping manage context and routing.
A big thank you to Wojciech for sharing his insights, and to everyone who joined us live.