Most discussions around Model Context Protocol (MCP) servers frame them as a standardized way to expose tools to AI agents. Files, APIs, and services are wrapped in schemas and made callable in a controlled manner.
That framing is accurate — but incomplete.
If MCP servers are treated only as tool gateways, we miss their larger architectural role: enabling governed, conversational agentic workflows where assumptions are explicit, alternatives are explored, and outcomes are explainable.
This post explores that broader opportunity using a concrete, enterprise-relevant use case:
Frontend Modernization Planning for a given website.
The Common Mental Model: MCP as a Tool Layer
Most early MCP implementations follow a linear pattern:
In this model:
- The agent owns reasoning
- The MCP server validates schemas and executes tools
- The server remains largely passive
This approach works for deterministic tasks. It breaks down when:
- Inputs are incomplete by default
- Multiple valid outcomes exist
- Assumptions must be surfaced
- Decisions must be defensible
MCP as a Conversational Orchestration Layer
MCP is not just a function-calling protocol. It enables structured, multi-turn conversations where the server can:
- Detect missing or ambiguous context
- Elicit clarification
- Enumerate bounded alternatives
- Enforce architectural and policy constraints
Elicitation
Elicitation is a standardized mechanism that allows an MCP server to dynamically request additional, structured information from a user during a tool’s execution. Instead of failing due to missing information or relying on unstructured follow-up, a tool can pause, ask for exactly what it needs, and then resume its work once the user provides the data.
This enables more effective, contextual, and robust human-in-the-loop workflows.
Sampling (Client Capability)
While sampling (sampling/createMessage) is a request sent by the MCP server, it relies on the client supporting the sampling capability. Servers don’t implement sampling handling themselves; they initiate sampling requests if the connected client supports it.
Use Case: Enables agentic behavior where a server needs the LLM’s help to complete a task (e.g., a Git server tool asking the LLM to write a commit message based on a diff).
A prompt-only agent will infer answers.
An MCP-based system can negotiate them explicitly.
The MCP server does not replace the agent.
It governs the quality and structure of the interaction
Use Case: Frontend Modernization Planning for a Website
Modernizing a frontend is not a single action — it is a decision process:
- What problem are we solving? Performance, maintainability, UX, SEO?
- How much risk is acceptable?
- Should modernization be incremental or disruptive?
- Which architecture best fits future needs?
High-Level Flow
Step 1: Site Analysis (Observation, Not Decisions)
The MCP server invokes deterministic tools to analyze the existing site:
- Page and routing structure
- UI patterns and components
- Framework indicators (e.g., jQuery, legacy SPA)
- Performance and responsiveness signals
- Accessibility indicators
Pseudo code
server.analyze({
url: "https://legacy-site.com",
signals: [
"routing_structure",
"ui_complexity",
"framework_indicators",
"performance_footprint"
]
})
At this stage, the system observes.
No modernization recommendations are made yet.
Step 2: Elicitation — Clarifying Modernization Intent
“Modernization” is ambiguous by nature. The MCP server must clarify intent before proposing strategies.
MCP Server TypeScript SDK documentation for elicitation code examples.
Pseudo code
server.elicit({
missing_context: [
"modernization_goal",
"framework_preference",
"seo_criticality",
"accessibility_target",
"browser_support",
"delivery_constraints"
],
reason: "Required to propose a viable modernization plan"
})Example interaction:
Server: Primary goal — performance, maintainability, or UX? User: Maintainability and performance Server: Framework preference? User: React or Next.js Server: SEO critical? User: Yes
This step prevents the most common failure mode in modernization efforts: misaligned assumptions.
Step 3: Sampling — Enumerating Modernization Paths
There is no single “correct” modernization approach. Sampling allows the MCP server to propose bounded, explainable options.
MCP Server TypeScript SDK documentation for sampling code examples.
Pseudo code:
server.sample({
decision_point: "frontend_modernization_strategy",
options: [
{
strategy: "incremental_strangler",
description: "Gradually replace pages with a modern stack",
impact: "medium",
risks: ["dual-stack complexity"]
},
{
strategy: "full_rewrite",
description: "Rebuild the frontend from scratch",
impact: "high",
risks: ["timeline and scope risk"]
},
{
strategy: "islands_architecture",
description: "Modernize high-value interactions only",
impact: "low",
risks: ["partial consistency"]
}
]
})The MCP server defines the decision space.
The agent retains decision authority.
Step 4: Agent Produces a Modernization Plan
The agent reasons over:
- Observed site signals
- Elicited goals and constraints
- Sampled modernization strategies
Example output:
Frontend Modernization Plan Current State: - Multi-page legacy site - jQuery-based interactions - Limited mobile optimization Assumptions: - SEO is critical - Gradual rollout preferred - React ecosystem acceptable Recommended Strategy: - Incremental strangler approach using Next.js - Migrate high-traffic pages first - Introduce a shared design system early Alternative Options: - Full rewrite (faster end state, higher risk) - Islands architecture (lower impact, slower payoff) Next Steps: - Proof of concept on 2–3 pages - Define component boundaries - Establish performance baselines
The result is decision-ready, not just descriptive.
Why This Is the Bigger Agentic Play
In this architecture:
- The agent performs reasoning and synthesis
- The MCP server governs context, assumptions, and options
- Tools provide deterministic observations
A useful mental model:
The agent reasons.
The MCP server governs the conversation.
This separation is what makes MCP-based systems scalable, auditable, and enterprise-ready.
Anti-Patterns to Avoid
- One-shot modernization recommendations
- Silent assumptions instead of elicitation
- Hardcoded architectural logic in prompts
- Treating MCP as a passive API wrapper
These patterns undermine trust and long-term maintainability.
Key Takeaway
If an MCP server only executes tools and never:
- Asks clarifying questions
- Surfaces assumptions
- Enumerates viable alternatives
then it is being underutilized.
Frontend modernization planning shows how MCP enables structured, explainable decision-making, not just smarter tool calls.
Final Thought
MCP servers aren’t just about giving agents tools.
They’re about designing systems where architectural decisions emerge from governed conversation.
That’s the bigger agentic play.
