From 1948ba7bef071a092270796d25232ec7fd412354 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Wed, 20 May 2026 16:53:39 +0100 Subject: [PATCH] docs: add project vision --- VISION.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 VISION.md diff --git a/VISION.md b/VISION.md new file mode 100644 index 0000000..b441664 --- /dev/null +++ b/VISION.md @@ -0,0 +1,32 @@ +# MCPorter Vision + +MCPorter should make any commonly supported MCP server usable from TypeScript, scripts, generated CLIs, and agent workflows with minimal setup. + +## Product Goal + +If an MCP server works in common MCP clients, it should be practical to use through MCPorter too. That includes local stdio servers, hosted HTTP/SSE servers, OAuth-protected providers, imported client configs, and ad-hoc endpoints. + +MCPorter should stay small enough to understand, reliable enough for automation, and clear enough that failures tell the user what to fix next. + +## What Good Work Looks Like + +- Compatibility fixes for commonly used MCP servers, transports, schemas, auth flows, and client config formats. +- Bug fixes with a clear reproduction, root cause, and verification path. +- Performance work that improves startup, listing, calling, generated CLIs, daemon behavior, or repeated tool use without adding much complexity. +- Small UI/UX improvements to CLI output, errors, help text, docs, and generated artifacts. +- Refactors that make the correct fix cleaner, easier to test, or easier to maintain. +- Tests and live/manual verification for behavior that can realistically be exercised. + +## Non-Goals + +- Localization. +- Major new product areas that are not about making MCP servers easier to discover, call, generate, type, host, or debug through MCPorter. +- Broad features that make the product harder to reason about without a strong compatibility or reliability payoff. +- Complex provider-specific flows when a small generic MCP/auth/transport improvement would solve the same class of problem. +- Cosmetic churn, large rewrites, or dependency/tooling swaps without a concrete user-facing benefit. + +## Triage Rule + +Autonomous work is appropriate when it improves compatibility, correctness, performance, small CLI UX, docs, tests, or maintainability within this vision and can be verified end to end. + +Ask first when the work changes product direction, adds a major feature, increases complexity substantially, needs unavailable live credentials, or cannot be verified with confidence.