What Is MCP and Is It Worth It? Part 2: Best Practices and Business Value
- Dave Findlay
- Oct 15
- 3 min read
In Part 1, we looked at what MCP is, why it’s gaining traction, and where it fits in the modern
GenAI architecture. In Part 2, we’re going to get more practical. We’ll explore what makes a good MCP design and how to evaluate its return on investment.
Because for CIOs, the question isn’t just “Can we do this?” it’s “Should we?”
What Makes a Good MCP Design
Good MCP design is what separates a messy lab experiment from a production-ready capability. It’s the connective tissue between user intent and enterprise execution.
Here’s what to look for:
1. Business-Aligned
Each tool should map to a real-world task or action that supports business value, not just an API call. For example, instead of defining a generic tool like runSQLQuery, define a more intentional one like getAverageOccupancyRate that handles context resolution, filters, and formatting internally.
This reduces hallucination risk, improves business trust, and clarifies intent.
But that doesn’t mean you need to define a tool for every single business metric. That can quickly become an engineering burden.
Many teams opt for a middle ground. For example:
Define a general-purpose tool like getMetric that takes in parameters like metricName, geography, timePeriod, and portfolioId
Add logic to resolve common terms like “my portfolio” or “last quarter” using user context
Expose a curated list of supported metrics and time ranges via enum definitions to avoid hallucinations
This way, you retain flexibility without sacrificing control.
2. Structured
MCP works best when your tool definitions follow a clear schema:
Name
Description
Parameters (with types, validations, and enums)
Examples (real-world examples of how the tool would be used)
Output format (e.g., JSON, text, chart config, etc.)
Consistent structure helps:
LLMs generalize across tools
Developers debug and maintain implementations
Product teams reason about what’s possible
3. Governed
Tools should only be callable under specific conditions:
Who is allowed to invoke this tool?
What contexts should it be available in?
Are there budgets or rate limits applied?
Think of this as enterprise-grade role-based access control (RBAC) for your GenAI solution.
4. Observable
You can’t govern what you can’t see. Your MCP implementation should:
* Log tool calls
* Capture input/output
* Track which tools are used by which users and why
This creates the auditability and feedback loop necessary to improve performance and safety over time.
Where Does the ROI Come From?
This is the part that matters most to CIOs: What’s the business case?
1. Lower Total Cost of Ownership
Instead of hardcoding logic in a dozen Python scripts across various LLM projects, MCP creates a central library of reusable actions. This means:
Faster time to market for new use cases (read: increase business user satisfaction)
Lower engineering effort per project (read: less cost per use case)
Less duplication of effort across teams (read: less code to maintain over time, ability to iterate faster. See point 1).
2. Faster Time to Value
Well-defined tools allow LLM agents to act with less guesswork and more confidence. That improves:
First-response accuracy
Task completion rate
User trust
When you spend less time fiddling with prompt engineering, you spend more time shipping value.
3. Reduced Risk
MCP lets you bake in compliance and security at the interface level:
Limit what LLMs can do
Validate inputs before execution
Mask or redact sensitive data
This prevents a lot of downstream cleanup from prompt injection, privacy violations, or compliance missteps.
4. Product Thinking
MCP shifts your mindset from project to product. You stop building one-off experiments and start building:
Shared definitions
Shared infrastructure
Shared context
Shared value
This amplifies the value of each new use case. Every tool you add to the MCP library becomes a building block for future capabilities.
So Is MCP Worth It?
That depends.
If you’re building small, throwaway use cases, probably not.
But if you’re building enterprise-grade GenAI capabilities that need to be safe, reusable, and scalable?
Then MCP isn’t just worth it — it may be the only path forward.
TL;DR
MCP is more than just a developer pattern. It’s a strategic enabler for scaling GenAI responsibly.
By combining structured design with business alignment and enterprise governance, MCP can lower costs, increase speed, and reduce risk.
If you’re investing in GenAI as a long-term capability, MCP should be on your radar.
At Fuse, we believe a great data strategy only matters if it leads to action.
If you’re ready to move from planning to execution — and build solutions your team will actually use — let’s talk.
