MCP Explorer

What problem existed?

The team had recently built an MCP Explorer to expose MCP capabilities and prepare for launch. The first version was intentionally built fast by a founder, so the team could start learning from the surface as soon as the protocol mattered.

MCP itself was still emerging. The protocol was young enough that the UX conventions for talking to it hadn’t settled. The work was about shaping what good MCP exploration should feel like before widespread adoption set the patterns for us.

The underlying system already held rich information about tools, schemas, capabilities, execution state, and connection health. Most of it was expressed in protocol-shaped structures. The opportunity was to surface that same information in a way that followed how developers move through a tool.

Why did it matter?

MCP is an exploration tool at its core.

Its value depends on helping users discover capabilities, understand what those capabilities do, execute them confidently, and learn how the system behaves.

As AI systems get more capable, understanding the capability landscape gets more important. The Explorer would be many users’ first contact with MCP inside the product. Discoverability, transparency, and comprehension were going to drive adoption.

The functionality already existed. The opportunity was making it visible.

What constraints existed?

Several real constraints shaped the work:

• The feature hadn’t fully launched, so user feedback was limited.
• MCP itself was still evolving and lacked mature design patterns.
• No backend changes were planned.
• No new APIs, data models, or capabilities were being introduced.
• Engineering bandwidth sat with broader platform priorities.
• The frontend depended on generated GraphQL artifacts that made local development slow without extra setup.

The job was improving usability, discoverability, and execution flow using infrastructure that already existed.

What role did I play?

I owned the design and updated the frontend, working from the protocol model alongside the founder and engineering.

My focus was making the system legible. I looked at how mature developer tools (GraphQL explorers, Swagger, Postman) handle discovery and schema exploration, surfaced capabilities the platform already held, defined the interaction model, and took the design into the production frontend, which engineering reviewed and shipped. The thinking and the building ran in parallel, which kept the design grounded in what the platform could actually do.

What options were explored?

Three directions came out of the exploration:

• A traditional UI refresh. Visual polish and design-system alignment.
• A bolder path. New capabilities or abstractions layered on top of MCP.
• A systems-visibility path. Treat the project as making information that already exists legible.

I pursued the third. The question became what already exists in the platform, and how to make it easier for users to discover, understand, and act on it. That reframe shifted the focus from feature creation to capability exposure.

What tradeoffs were considered?

The main tradeoff was protocol fidelity versus usability.

The underlying MCP model contains technical concepts that are useful to advanced users and can be difficult for newcomers. The design created a clearer pathway through the existing system. Protocol concepts stayed visible where they served users. Implementation details stayed in the background where they didn’t.

The goal was helping users build an accurate mental model of the system without requiring deep protocol knowledge up front. Abstraction for its own sake wasn’t the point.

How did UX, engineering feasibility, and business strategy intersect?

The project deliberately avoided backend changes and focused on raising the value of existing investments.

UX gains came from improved discoverability, comprehension, and execution flow. Engineering risk stayed low because the work reused existing APIs, data structures, and platform capabilities instead of building new dependencies. Business value came from a stronger Explorer that improved onboarding, experimentation, and adoption of MCP capabilities without significant new engineering investment.

That alignment let the project move fast while still delivering meaningful user value.

How was AI used in the process?

AI became a critical part of the discovery workflow.

I used AI as a systems-analysis tool. Externally, I asked it to map adjacent developer tooling ecosystems (GraphQL explorers, Swagger, Postman) to see how mature systems handle discoverability, schema exploration, execution workflows, and capability visibility. Internally, I asked it to interrogate the codebase and map the data already available within the platform.

The internal half looked like this:

Interrogate this codebase and map what's already available to
show in the UI but isn't surfaced today: capability metadata,
parameter and schema descriptions, categorization, connection
and execution state, health and status. For each one, tell me
where it lives and what it would take to expose. Cite the
files so I can read them myself.

That work surfaced opportunities that weren’t immediately visible in the UI:

• Capability metadata that was already available.
• Parameter descriptions and schema information.
• Tool categorization data.
• Connection and execution state.
• Organization context.
• Health and status information.

What used to take extensive audits, documentation reviews, and manual system tracing collapsed into a much tighter loop. I could ask the codebase the same question three different ways until I understood it.

What was learned?

A lot of usability work is actually visibility work, a pattern that keeps showing up in modern software. Complex systems usually already hold the information users need to succeed. The work is organizing, surfacing, and contextualizing it in a way that supports understanding.

The project also showed how AI can compress the distance between research, implementation understanding, competitive analysis, and design execution.

What was the outcome?

A production-ready UX layer for the MCP Explorer, built entirely on top of existing capabilities.

Key improvements:

• Clearer schema presentation.
• Improved navigation and filtering.
• Visible capability and connection state.
• Improved execution flow.
• Reduced setup friction through contextual defaults.
• Greater visibility into the system’s available functionality.

No new features. No backend behavior change. The project raised the usability, discoverability, and clarity of capabilities that already existed.

More broadly, it demonstrated a modern design workflow where AI serves as an accelerator for systems understanding. Design moved from discovery to implementation with much less organizational overhead while staying grounded in technical reality.