HasMCP
No-code GUI MCP Server Framework with built-in Auth & Logs
31 followers
No-code GUI MCP Server Framework with built-in Auth & Logs
31 followers
Generate and deploy Model Context Protocol (MCP) servers from your API in seconds. A secure, opensource Streamable HTTP bridge between API endpoints to LLMs with built-in auth, realtime logs, request/response interceptors and secret/vault manager. No more asking users to install Python or Nodejs to their PC or expose API keys. Get your 7/24 online, token optimized, ready to use MCP Server URL. Make your product available in ChatGPT, Claude, Gemini, VSCode, Cursor and any LLMs/AI now.
Hi PH Community!
I was working on MCP Servers and I found it is hassle to create one using the tools/frameworks. But not only the creation process, the servers had be downloaded via npx or python at that time. As an alternative, I had to wrap an existing endpoint by writing tons of code. Another thing is the change on the official MCP specs was lightning fast and are not simple just to update your server, you have to write code again to catch it up with the latest spec.
After understanding the underlying protocol communication, I decided to remove this bottleneck from developers life and democratize to access MCP Server with just sharable URL instead of arbitrary local code execution.
Another big challenge was token optimization; I shouldn't have been just returning the what endpoint returns, that was including a lot of unnecessary sometimes confidential information, so an interceptor idea was born. HasMCP supports Jmespath and JS interceptors that you can modify the payload before returning to the client. Either you need to remove a PII column or just prune the data that you need, HasMCP is here to help.
Authentication is one of the other pain points in MCP world; HasMCP supports OAuth2 authentication with elicitation when the OAuth2 client credentials are defined in the provider. So, no more thinking about how I am going to authenticate the user. It is ready to use with just standard OAuth2 client input values. The access/refresh tokens are stored in encrypted format in the session storage. If your API does not support OAuth2, I got you covered too: Your users can define secrets (encrypted environment values) to send specific header values on tool calls.
Realtime access logs and metrics gives you full visibility on what is happening behind the scene. What is the request/response payload in JSONRPC 2.0 format, what MCP client/server side notifications have been sent. What methods have been called, all available in realtime only (not stored)!
When we expose MCPs to LLMs we give full control on the tools, another killer feature of HasMCP is toggling the tools what is being exposed to LLM in realtime. You can simply toggle the ones and authorize access for LLMs and this takes immediate affect, so you can kill a tool or add new one on the fly. This increases the security and give the user to have granular control what is allowed or not. While talking to one LLM you can expose a subset of read only tools whereas some superusers would need to use the write endpoints, this selection is just a toggle in HasMCP. Once you created an API provider, you can create unlimited servers from it, you can just focus on the secure design of your system.
HasMCP is API first, and majority of these functionality also available in opensource community edition. It is time to make your product 7/24 available to ChatGPT, Gemini, VSCode, Cursor, Claude, and all other LLMs that has MCP client with realtime governance. Today is the day to build an MCP server for your product!
@mustafat Congrats on the launch, Mustafa! Love the “shareable MCP URL + OAuth + realtime logs” angle—finally an alternative to “please run this random npx” 😅
When MCP specs change this fast, can we pin a server to a specific spec/version and get a clear upgrade diff when it’s time to migrate?
Thanks @hijacey . Sorry my late reply, somehow the comment was not visible to me.
>When MCP specs change this fast, can we pin a server to a specific spec/version and get a clear upgrade diff when it’s time to migrate?
Currently, both the client and server tries to match the protocol version and more importantly they share the capabilities correspondingly. How it works in general is, the MCP client and server shares their capabilities on initialize method call. So, if the new spec has a new capability but not supported either by client or server, they are not using it at all.
If you have further questions do not hesitate to reply, would be happy to help.