Building an Optimal MCP Server: Consolidation Over API Bloat

Building an Optimal MCP Server: Why You Only Need Five Core Endpoints

The Model Context Protocol (MCP) is driving a rush to expose internal systems to LLMs through custom server implementations. Many engineering teams are falling into a trap of creating unique endpoints for every action, leading to a massive explosion of tools that destroys system efficiency.

Why This Matters

Technical reality involves managing thousands of resource types across fragmented OpenAPI specifications, such as Microsoft Azure’s multi-file definitions. Relying on LLMs to guess specific resource names increases token costs and error rates, whereas a consolidated primitive-based architecture ensures predictability and scalability for AI agents.

An AI agent is only as smart as the tools it is given; messy and inconsistent toolsets consume excessive compute resources and increase latency. By shrinking the toolset to fundamental building blocks, architects achieve predictability where the AI follows a strict logical path for every operation regardless of the underlying cloud provider.

Key Insights

• The Schema Endpoint allows clients to dynamically query required fields for a resource type, eliminating malformed requests through dynamic discovery.
• A unified Execution Endpoint routes requests based on resource type and action (create, update, patch), consolidating thousands of potential individual tools into a single primitive.
• Microsoft Azure often requires manually stitching multiple OpenAPI schema files to define resource types, presenting a fragmented specification landscape compared to consolidated providers.
• The AWS Cloud Control API provides standardized CRUD actions across resource types out of the box, serving as a benchmark for predictable interface patterns.
• MechCloud’s translation layer maps natural language prompts to structured metadata, reducing token costs and preventing LLM hallucinations during resource identification.

Practical Applications

• Use Case: MechCloud REST Agent maps conversational prompts like ‘secure storage bucket’ to specific resource types across GCP, Azure, and Kubernetes using a semantic search endpoint.
• Pitfall: Creating separate MCP tools for every cloud resource type (e.g., create-vm, delete-vm) results in a bloated surface area that overwhelms LLM context windows.
• Use Case: AWS Cloud Control API implementation allows developers to manage disparate services using the same predictable pattern for creation, reading, and deletion.
• Pitfall: Pushing the responsibility of resource name translation to the LLM client causes excessive token usage and failures with outdated or hallucinated API versions.

References:

• https://dev.to/mechcloud_academy/building-an-optimal-mcp-server-why-you-only-need-five-core-endpoints-45nj