Keinsaas Navigator: an MCP-first chat workspace you host yourself
Formerly Better Chatbot. Navigator is an open-source AI workspace for agents, MCP and workflow automation.
At a glance
- What is it?
- Navigator (the repository formerly named Better Chatbot) is a Next.js and Vercel AI SDK application that turns MCP servers, custom agents and visual workflows into @mention tools inside a chat window. The interesting part is not the chat UI; it is that the tool layer is user-editable and shareable.
- Who is it for?
- Adopt Navigator if you already run one or more MCP servers and want a shared, self-hosted surface where teammates can invoke them without writing a client. Skip it if you want a single-vendor assistant with a managed SLA, or if you cannot run a database and blob store alongside the app, since the Vercel path expects Neon, Upstash and Vercel Blob.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Navigator is trying to fill: MCP servers with no shared front end
Model Context Protocol servers are easy to run and awkward to share. Each developer wires their own client, keeps their own config file, and the result is a set of tools that exist on one laptop. Navigator's pitch is that the tool layer becomes part of the application: the README describes MCP protocol support as a first-class feature, alongside web search, JS and Python execution, and data visualization as default tools. The audience is individuals and small teams who want a chat interface they control, with the ability to hand a colleague a working agent rather than a setup document. The README also frames the project as inspired by ChatGPT, Claude, Grok and Gemini, which sets the expectation: this is a consolidation play, not a new model. If your problem is that your MCP servers are invisible to everyone except the person who configured them, Navigator is aimed squarely at you.
How the pieces connect: chat, MCP client, agents and published workflows
The mechanism visible in the README is an @mention dispatch layer over a chat session. A user types something like @tool('web-search') or @mcp("playwright") and the model decides how to call that server, potentially several times, before returning a final message. The README's own sample prompt asks the model to search for information and then drive a browser through playwright-mcp, clicking a login button and entering an email address. Two other object types plug into the same namespace. Custom agents are definitions with their own system prompt and tool access, invoked as @agent_name; the README's example is a GitHub Manager agent with issue and PR tools. Visual workflows are graphs of LLM nodes for reasoning and Tool nodes for MCP execution, and once published they become callable as @workflow_name. So the data flow is: workflow or agent definition plus MCP server list, resolved at chat time into tool calls, executed server-side, streamed back into the conversation. The README also mentions a tool choice mode and presets, and a realtime voice assistant with what it describes as full MCP tool integration.
Running it: the Vercel button, the Docker Compose path and the env keys
There are two documented install routes. The fast one is the Deploy with Vercel button, which clones the repository and prompts for environment variables. The README states that BETTER_AUTH_SECRET is required and that at least one LLM provider key is required, listing OPENAI_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY and ANTHROPIC_API_KEY, with the note that you can add all of them. The button's configuration also wires Neon for storage, Upstash for KV and Vercel Blob, which tells you what the hosted path assumes about persistence. The second route is a Docker Compose quick start, and the table of contents lists separate guides for Docker hosting and Vercel hosting. Beyond the environment variables, the README points to .env.example for the full list, and to guides covering MCP server setup and tool testing, file storage drivers, system prompts and chat customization, OAuth sign-in, adding OpenAI-like providers, and end-to-end testing. The repository is TypeScript, MIT licensed, and the default branch is main.
Where the design gets in the way: sharing, credentials and the demo prompt
The collaboration story is the weakest documented area. The README says you can share agents, workflows and MCP configurations with your team, but it does not describe the permission model, what happens when a shared MCP server needs per-user credentials, or how a shared workflow behaves when the underlying tool is unavailable. That matters because MCP servers frequently hold tokens. The preview prompt is a good illustration of the boundary: it instructs the model to enter a specific personal email address into a Google login form, which is fine as a demonstration and a poor pattern for a shared workspace. A second limitation is the hosting assumption. The free-tier language around Neon, Upstash and Vercel Blob is convenient, but it means the application is not a single binary you drop on a box; the Docker path exists, and the README points to a separate file storage driver guide, which implies storage is pluggable and therefore something you must choose and test. Third, the README's own note that the project is evolving quickly and shipping features constantly is a maintenance warning, not a selling point: expect configuration surfaces to move between minor releases such as v1.24.0, v1.25.0 and v1.26.0.
What you give up compared with a plain MCP client
The obvious alternative is a desktop MCP client such as Claude Desktop, or a coding agent that speaks MCP directly. The difference in approach is real. A desktop client keeps tool configuration local to one machine and one user, requires no database, no auth secret and no blob storage, and starts in seconds. Navigator inverts that: it adds a web UI, multi-user sign-in via Better Auth, a database, file storage and a deployment target, and in exchange the tool definitions become shareable artifacts that a non-developer teammate can invoke by typing @workflow_name. If your MCP usage is personal and your tools are local, the desktop client is less machinery for the same outcome. Navigator only pays for itself when more than one person needs the same tool set, or when the workflow graph itself is the thing you want to reuse. Note also that Navigator is a client and a host: the topics list includes mcp-server alongside mcp-client, so the repository is positioned on both sides of the protocol, but the README's detail concentrates on the consuming side.
Maintenance, versioning and the MIT licence in practice
Navigator ships as versioned releases, with v1.26.0 dated 2025-11-22, v1.25.0 on 2025-10-30 and v1.24.0 on 2025-10-06, roughly a monthly cadence across those three. That is a reasonable rhythm for a project of this shape, and it also means upgrade work: a Next.js application with an auth layer, a database and a plugin-style storage driver has several places where a minor bump can require attention. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; it also means no warranty and no obligation on the maintainers to fix anything. Because this repository is a fork lineage (the README credits the original author and the repository now carries the keinsaasforever namespace), check which upstream you are tracking before you build a fork of your own. This is a description of the licence text, not legal advice; if you are embedding Navigator in a product, have counsel read the MIT terms against your distribution model.
Who should deploy Navigator, and the three things to check first
Deploy it if you have a small team, at least one MCP server worth sharing, and someone comfortable operating a Next.js app with a database and object storage. The Vercel button plus a single provider key is the shortest path the README offers, and the Docker Compose path covers the case where you want it off Vercel. Do not deploy it if you need a vendor SLA, if your tools are strictly single-user, or if nobody on the team will own upgrades across releases like v1.26.0. Three checks before you commit: confirm your MCP servers behave under the @mcp mention flow described in the MCP setup and tool testing guide rather than assuming the preview works for your server; confirm your intended storage backend appears in the file storage drivers guide, since the hosted path defaults to Vercel Blob; and confirm the OAuth sign-in guide covers the identity provider you actually use, because BETTER_AUTH_SECRET is the only auth variable the deploy button names. If those three pass, the workflow graph is the feature that justifies the extra infrastructure over a local MCP client.
Editorial conclusion
Adopt Navigator if you already run one or more MCP servers and want a shared, self-hosted surface where teammates can invoke them without writing a client. Skip it if you want a single-vendor assistant with a managed SLA, or if you cannot run a database and blob store alongside the app, since the Vercel path expects Neon, Upstash and Vercel Blob. Before committing, verify the current MCP client behaviour against your own servers, check that the OAuth sign-in path you need is documented, and read the file storage driver guide to confirm your target backend is supported.
Community notes