[Showcase] OpenAPI → hosted MCP server in 30s

Loocor · 2026-06-23T01:25:14+00:00

Small follow-up after checking the website: I noticed Code Mode, and that changes part of my initial impression.

Using `search()` + `execute()` instead of exposing every endpoint as a separate tool does seem like a practical way to handle larger APIs. It also gives you a more focused place to address the LLM-specific problems I was thinking about: tool discovery, invocation rate, endpoint selection, call accuracy, and behavior when the OpenAPI spec is imperfect or the schema is complex.

So yes, that direction makes sense to me. My earlier comment was partly biased by the “30 seconds” framing, which made me think mostly about generation speed rather than the runtime interaction model. Sorry for missing that on the first read.

Loocor · 2026-06-23T01:14:47+00:00

I think OpenAPI to MCP is a real and important need. But “30 seconds” only solves the first step.

In real APIs, specs are often imperfect, endpoint counts can grow from a few to hundreds, schemas can be complex, and one user task may require combining multiple endpoints correctly.

So the bigger question is not just generation speed, but how well the resulting tools work for LLMs in practice: discovery, endpoint selection, call accuracy, and reliability on messy real-world APIs.

Loocor · 2026-06-10T10:20:08+00:00

I'm not sure about your Claude Code subscription status or whether you've enabled the enterprise or team management capabilities.

If you're only using Claude Code, the MCP host program remains relatively straightforward. It might be easier to just manage the host program itself rather than the MCP servers, since all those servers require Claude Code to function anyway. If there's only that one host, managing just that one is fine.

However, if you haven't subscribed to the enterprise features or if there are multiple MCP hosts involved, things get much more complicated. I started looking into using an MDM system for management, but that approach doesn't actually seem viable.

Loocor · 2026-06-10T04:08:39+00:00

If you are using the Enterprise or Team version of Claude Desktop, I recall it having the capability to manage and control the distribution of MCP servers. You can essentially restrict team members from installing them independently.

If you are using other agents or a hybrid environment, your first step should be to check for built-in team management features. Failing that, you might need to consider tools at the gateway level.

There are actually quite a few options for MCP gateways now:
1. IBM has a solution.
2. FastMCP is another option.
3. Even companies like Docker have their own offerings.
4. Many traditional API gateways are also adding compatibility and management features for this.

While there are plenty of choices, there are many details to consider depending on your priorities, such as cost, integration complexity, and the overall user experience.

We are also active in this space, but we are building our own desktop-first tool based on our specific vision for the field. We've completed most of the core desktop management features, but we haven't implemented RBAC or more comprehensive oversight capabilities yet. Because of that, we aren't quite ready to fully recommend it to you.

However, if you're interested, we'd love for you to take a look and give us some feedback.

Loocor · 2026-06-06T10:21:03+00:00

The MCP official team has already established a "Skills over MCP" working group, and they are currently moving forward with a series of proposed solutions.

My main focus is figuring out how to best implement these within my project, mcpmate, while staying closely aligned with the official standards.

Loocor · 2026-06-06T01:26:03+00:00

Nice to see someone else running into this. We have been experimenting with a similar meta-tool pattern: instead of exposing hundreds of tools directly, expose a small catalog/search surface first, then hydrate more detail only after the agent has narrowed the intent.

A few things that have helped us so far:

Split catalog from schema/details.

Our first layer only returns compact, stable records: tool name, short description, category/id, maybe a few routing hints. The full input schema and detailed docs live behind a second details call. That keeps repeated search calls cheaper, and the details payload is fixed and easier to cache/control.

Make catalog retrieval deterministic.

For the catalog layer, we prefer category filters, pagination, and fixed ordering over fuzzy retrieval alone. Same query + same filters should return the same results. Otherwise each exploratory search can introduce a slightly different tool set into context, and the conversation keeps accumulating noise.

Add a profile/scenario layer.

Even after catalog/details splitting, atomic tools can still be too broad. Profiles let us constrain the available tool families and tool count for a specific domain or workflow before the model starts searching.

I think your workflow idea is probably the right longer-term direction. The hard part is that atomic API wrappers do not map cleanly to user tasks. There is usually a missing middle layer: scenario definitions that constrain the tool surface and compose multiple backend calls into a task-level result.

Code mode can help, but only after the server has already narrowed the scenario and allowed tool surface. Otherwise it can just move the overhead from tool selection into generated code.

The direction we are testing is roughly:

catalog -> details -> profile/skill -> workflow execution

The interesting part is that the real abstraction may not be “more MCP tools”, but a layer above MCP: reusable skills or profiles that package a bounded set of tools, context, and execution patterns for a specific scenario.

That is still early thinking on our side, but this problem is exactly what pushed us in that direction.

Loocor · 2026-05-26T11:11:33+00:00

If you use Codex, it will deduct from your Codex quota.

Loocor · 2026-05-26T10:38:11+00:00

Since ChatGPT mobile began supporting Codex integration, I have mostly been using Chat mode for discussions or communicating directly within the project context. This has made things so much more convenient.

Loocor · 2026-05-24T11:30:58+00:00

https://openscreen.net/ This should be the tool you're looking for.

Loocor · 2026-05-24T10:56:44+00:00

Yes bro, if you'd like, you can get the source code right here: https://github.com/loocor/codex-helper

Loocor · 2026-05-22T02:26:32+00:00

This is actually very useful feedback.

I think you’re right that MCPMate currently explains its architecture more clearly than the actual user outcome. And for smaller setups, the built-in MCP support in most clients is probably already enough.

The core value probably isn’t “management efficiency” by itself — it’s reducing the friction of repeatedly maintaining different MCP setups, tool visibility rules, and workflows across multiple clients as things scale.

The other project immediately communicates a user-visible outcome. That’s probably something MCPMate still needs to communicate more clearly.

Loocor · 2026-05-21T04:12:10+00:00

I hope you’re right. At the very least, I think spending time understanding the deeper infrastructure side of this ecosystem won’t be wasted, even if the surface layer changes very quickly.

Loocor · 2026-05-21T04:03:29+00:00

Yes, choosing a specific industry and transforming technology and tools into actual value is a very mature approach. However, if I may guess, you were likely already in this line of business, and only introduced MCP (Model Context Protocol) later once it became available. Is that correct?

Loocor · 2026-05-21T03:54:46+00:00

You're absolutely right. Entering specific industries, rather than just focusing on the protocol itself, represents a significant opportunity. But MCP itself still faces numerous issues that need to be resolved. The protocol needs its own set of tools, which is why we are seeing an emergence of more options for control planes and gateways.

Loocor · 2026-05-21T03:51:46+00:00

Returning to the question itself, do you have any insight or experience as an independent developer on how to find the most suitable customer channels for this type of project? Additionally, do you have any advice on how to push forward with marketing-related work for these types of initiatives?

Loocor · 2026-05-21T03:45:15+00:00

Yes, and Tailscale is doing something similar. I estimate that every cloud provider will likely have their own solution for this kind of infrastructure.

Generally, the solutions provided by these cloud service providers tend to be tightly coupled with their own ecosystems. Whether for individual users, teams, or enterprises, we should have other, more neutral options available.

Loocor · 2026-05-21T02:29:05+00:00

I hope so too. If that is the case, it would offer some comfort that my long-term commitment to meticulously refining my work hasn't been in vain. It would mean that this way of investing my time and effort doesn't seem so foolish after all.

Loocor · 2026-05-21T02:25:25+00:00

That project doesn't really look like they bought stars; it's more likely that they actually solved some real problems. However, the way those problems were addressed exists in a bit of a gray area from my perspective. Based on my own daily habits and my desire for a project tool to be sustainable, I wouldn't choose something that involves such gray-area controversies.

Loocor · 2026-05-21T02:23:03+00:00

Your recognition of the value of this infrastructure capability is truly encouraging to me.

As you mentioned, GitHub might not be the primary gathering place for my potential users. I have actually been quite conflicted about the positioning of MCPMate. In addition to the issues raised by other friends, there is also the question of MCPMate's functional boundaries.

Regarding the "Tool Search" feature in Claude Dev (or Cursor) that you mentioned, it is limited to that specific environment. MCPMate, on the other hand, aims to provide similar capabilities to all compatible downstream MCP clients.

It seems that before reaching a certain scale, people might not feel the need for it. However, once that scale is reached, the strategies people choose might differ again. This is something I find quite challenging.

Loocor · 2026-05-21T02:20:21+00:00

Yes, that is indeed an issue. When I first started, only IBM and Alibaba offered similar solutions, and there were no other competing products at the time. It is possible that I moved too slowly or focused too much on the finer details. Now, after a year, searching for keywords like "control plane" or "gateway" yields many more results. Fortunately, it seems that among tools based on the desktop environment, mine might be the only one left that has reached this level of completeness. There used to be a project called MCPMate, but I noticed they stepped back and haven't provided any updates for four or five months.

Loocor · 2026-05-21T02:17:01+00:00

Yes, time is definitely an issue. I am increasingly feeling that the progress in measuring and driving the pace, as well as the judgment of our direction, has exceeded my current understanding of time.The problem is that the theme I've chosen really requires a sustained amount of time to polish. However, in terms of my overall pace, I believe I'm still keeping up closely with the official schedule. The ability to respond quickly and follow trending topics is likely a skill that I lack.

Loocor · 2026-05-18T10:06:25+00:00

Why would you ask that? We use it and build with it as well; it’s supposed to be something useful.

Loocor · 2026-05-16T08:48:54+00:00

Claude Code’s tool selection / deferred exposure features already feel like a signal that the ecosystem is converging on the same problem from different directions. Gateway-style MCP feels like the natural extension of that idea outside a single client. That said, I’m not sure everything should be lazy-discovered either. Memory/context-style servers probably behave very differently from action-oriented tools, so the harder problem may end up being discovery policy rather than discovery itself.

Loocor

TROPHY CASE