Do not start MCP adoption by asking whether a framework is powerful enough. Start by asking what the user must see, approve, and recover from.
Start With The Surface
A plain MCP server is enough when the product only needs to expose a tool, resource, or prompt to an existing client. It is easier to test, inspect, and replace.
An MCP App is more defensible when the workflow needs a visible widget: a chart, map, file browser, progress panel, or other state the user must inspect before the next action.
- Use a server when tool access is the main product.
- Use an app when the user needs a visible decision surface.
- Use a client or agent wrapper when your product must orchestrate other MCP servers.
Use mcp-use As A Reference Stack
mcp-use is useful because the official docs and README show several MCP surfaces together: TypeScript and Python server SDKs, MCP Apps with React widgets, an Inspector, deploy tooling, and agent/client libraries.
That makes it a good comparison object, not an automatic default. The full stack is only worth adopting when your workflow needs those surfaces together.
Checklist Before Building
- Name the host: ChatGPT, Claude, an internal tool, or your own product.
- Name the user action that must be visible before the next step.
- Name the data or account boundary the workflow can touch.
- Name where errors, logs, reconnect state, and auth failures will be inspected.
- Try the server path first, then add a widget only if the workflow loses clarity without it.
When To Skip The App Layer
Skip the app layer for a private automation, a one-off internal script, or a workflow that only returns structured data. A widget can make auth, state, and support harder if it does not change the decision.
Sources
- mcp-use·Official doc·Core sourcemcp-use GitHub repository
- mcp-use·Official doc·Core sourcemcp-use documentation
- mcp-use·Official doc·Supporting sourcemcp-use releases
