nextjs-mcp-kit

Ein MCP-Server, ein MCP-Client und eine provider-agnostische Chat-UI für Next.js App Router — als Route-Handler, Komponenten und typisierter State, die du installieren kannst.

Gib deiner App einen kleinen Chat, der tatsächlich Dinge über deine App weiß.

Smart-Chat — Antworten sind solche, die du geschrieben hast, von dir hochgeladene Dokumente

• die Tools, die du hinzufügst Du fügst die Antworten über ein Formular im Browser hinzu, um das Tool zu erstellen. Kein Nachtrainieren, keine Vektordatenbank, kein erneutes Deployment.

Es ist bewusst nicht schlau. Es ist der kleine Chat, der Hallo sagt und deine Öffnungszeiten kennt, und es dauert etwa eine Minute, bis man einen hat.

npm i nextjs-mcp-kit && npx nextjs-mcp-kit init

nextjs-mcp-kit — Scaffolder-Optionen

npx nextjs-mcp-kit init // in das aktuelle Verzeichnis scaffolden

npx nextjs-mcp-kit init --force // vorhandene Dateien überschreiben

npx nextjs-mcp-kit init --dir web // in ./web scaffolden

Springe dann zu Dein erstes Tool in 60 Sekunden.

Sechs Oberflächen, bewusst getrennt:

Füge ein Tool aus dem Browser hinzu, und es ist sofort im Chat nutzbar — und wird über MCP an alles ausgeliefert, das auf deine App zeigt, einschließlich des Clients von jemand anderem.

Related MCP server: Example Next.js MCP Server

Dein erstes Tool in 60 Sekunden

Keine API, kein Schlüssel, kein Code. Führe npm run dev aus, öffne /add-tool und lasse die erste Option auf „Gibt den Text zurück, den ich schreibe" stehen:

Lass die Parameter leer. Klicke auf Tool hinzufügen.

Öffne nun /personal-chat, aktiviere opening_hours und frage „Sind Sie am Samstag geöffnet?"

Das Modell antwortet „nein — am Wochenende geschlossen", und unter der Antwort steht, dass opening_hours ausgeführt wurde, und es zeigt genau, was das Tool zurückgegeben hat. Das wusste es nicht. Du hast es ihm vor dreißig Sekunden über ein Formular gesagt.

Das ist der gesamte Kreislauf. Alles andere in dieser README ist dieser Kreislauf mit mehr Optionen.

Warum die Beschreibung wichtiger ist, als sie aussieht

Die Beschreibung ist keine Dokumentation — sie ist das, wonach das Modell entscheidet, ob es das Tool überhaupt aufruft. "opening hours" wird in der Hälfte der Fälle ignoriert. "The shop opening hours. Call this when asked when we are open." wird aufgerufen. Eine vage Beschreibung bedeutet ein Tool, das registriert und nie ausgewählt wird.

Wofür das gut ist

Ein winziger Chat für deine Besucher. Nicht schlau genug, um ein Support-Agent zu sein, und will es auch nicht sein. Schlau genug, um jemanden zu begrüßen und die sechs Fragen zu beantworten, die deine App tatsächlich gestellt bekommt — mit Antworten, die du geschrieben hast. Jede dieser Antworten ist ein skill-Tool: ein Name, eine Beschreibung und der zurückzugebende Text.

Antworten, die auf dem basieren, was du ihm gesagt hast. Wenn ein Tool zur Frage passt, ruft das Modell es auf und antwortet mit dem, was zurückkam — nicht mit dem, woran es sich halb erinnert, wenn es um Geschäfte im Allgemeinen geht. Eine Frage, die deine Tools abdecken, wird von deinen Tools beantwortet.

Du kannst immer sehen, was passiert ist. Jede Antwort, die ein Tool verwendet hat, nennt es und zeigt, was es zurückgegeben hat. Wenn die Antwort aus deinem Text stammt, kannst du es beweisen; wenn das Modell von selbst geantwortet hat, ist der Trace leer, und das kannst du auch sehen. Kein Rätselraten, welche du bekommen hast.

Keine stillen Ausweichlösungen. Wenn ein Provider keine Tools aufrufen kann oder einem Ollama-Modell die Fähigkeit fehlt, erhältst du eine 503 mit dem Grund, bevor der Turn läuft — niemals eine Antwort, die die von dir aktivierten Tools still ignoriert hat.

Kostenlos im Betrieb. Ollama ist lokal, ein Besucher-Chat kostet also nichts pro Nachricht, und keine Daten verlassen die Maschine. Wechsle zu Claude für einen besseren Chat mit denselben Tools — der Picker zeigt 💳 für einen kostenpflichtigen Turn, 🖥️ für einen lokalen.

Es ist auch ein MCP-Server. Dieselben Tools, die du aus dem Browser hinzugefügt hast, werden über MCP bereitgestellt, sodass Claude Desktop — oder der Client von irgendjemandem — auf deine bereitgestellte App zeigen und sie verwenden kann. Siehe Einen MCP-Client verbinden.

Welche Seite du deinen Besuchern gibst

/smart-chat ist die Seite, auf die du sie zeigst. Eine Frage rein, eine Antwort raus — sie prüft jedes Tool, das du registriert hast, verwendet das passende und sagt, welches ausgeführt wurde. Keine Unterhaltung, die gepflegt werden muss, kein Verlauf, der gespeichert werden muss, nichts, das ein Besucher konfigurieren muss.

// app/ask/page.tsx — your public "ask us anything" page
export { SmartChatPage as default } from 'nextjs-mcp-kit/pages';

Oder füge einfach die Komponente in eine eigene Seite ein:

import { SmartChat } from 'nextjs-mcp-kit/components';

/personal-chat ist die Seite für dich: eine vollständige Unterhaltung, Anweisungen und eine Checkliste, welche Tools diese Unterhaltung verwenden darf. Hier probierst du ein neues Tool aus, bevor du jemand anderen in seine Nähe lässt.

/add-tool und /mcp-dashboard gehören ebenfalls dir, nicht deinen Besuchern. Keines von beiden hat eine Authentifizierung — platziere sie hinter deiner eigenen oder scaffold sie gar nicht erst in die öffentliche App.

Funktioniert mit Ollama (lokal, kostenlos) und Claude (Anthropic). Einen dritten Provider hinzuzufügen ist eine Datei und ein Array-Eintrag.

Installation

Erfordert Next.js 16+ und Node 20.9+. Der Peer-Bereich ist bewusst >=16.0.0 statt >=15.0.0: 16 ist die einzige Hauptversion, gegen die das gebaut und getestet wurde, und ein Peer-Bereich sollte beschreiben, was tatsächlich verifiziert wurde, nicht was vielleicht zufällig funktioniert. Bei Next 15 meldet npm i einen Peer-Konflikt — das ist das beabsichtigte Signal, kein Bug.

In eine bestehende Next.js-App

npm i nextjs-mcp-kit
npx nextjs-mcp-kit init

init schreibt die Route-Handler und /chat. Es fasst dein Root-Layout nicht an — füge selbst zwei Zeilen hinzu:

// app/layout.tsx
import { GlobalProvider } from 'nextjs-mcp-kit/context';
import 'nextjs-mcp-kit/styles.css';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <GlobalProvider>{children}</GlobalProvider>
      </body>
    </html>
  );
}

Dann cp env.local.example .env.local und npm run dev.

Eine Komponente importieren: das Eine, worüber Leute stolpern

Komponenten werden nicht aus dem Paket-Root exportiert. Das schlägt fehl:

import { AgentChat } from 'nextjs-mcp-kit';
// The export AgentChat was not found in module .../dist/index.js [app-rsc]
// Did you mean to import initialAgent?

Das funktioniert:

import { AgentChat } from 'nextjs-mcp-kit/components';

Der Root-Einstieg ist absichtlich server-sicher — siehe Exports. Faustregel: Wenn es rendert, ist es nicht im Root.

Den Import zu korrigieren ist notwendig, aber nicht ausreichend: AgentChat benötigt /api/providers, /api/chat und /api/instructions in deiner App und GlobalProvider darüber. npx nextjs-mcp-kit init schreibt die Routen; das Layout gehört dir. Eine vollständig funktionierende App — plus eine Troubleshooting-Liste in der Reihenfolge, in der Dinge tatsächlich kaputtgehen — gibt es im examples-Branch.

Eigenständig, aus einem leeren Verzeichnis

mkdir my-app && cd my-app
npm init -y
npm i nextjs-mcp-kit
npx nextjs-mcp-kit init          # detects the empty dir, writes a whole app
npm i next react react-dom
npm i -D typescript@^5 @types/node @types/react @types/react-dom
cp env.local.example .env.local
npm run dev

typescript@^5 ist bewusst festgepinnt. Ein bloßes npm i -D typescript löst derzeit zu TypeScript 7 auf, dessen umstrukturiertes lib/ Next 16 nicht erkennt — es meldet „du hast die erforderlichen Paket(e) nicht installiert", obwohl es installiert ist, und der Build schlägt fehl.

Konfiguration

OLLAMA_API_URL=http://localhost:11434   # 11434 is Ollama's default port
ANTHROPIC_API_KEY=                      # empty is fine — runs local-only
NEXTJS_MCP_DATA_DIR=                    # defaults to ./.data

ANTHROPIC_API_KEY leer zu lassen ist ein unterstützter Modus, kein defekter: Der Picker zeigt Claude als nicht verfügbar mit dem Grund, und Ollama funktioniert weiterhin. Das ist der Sinn von isAvailable() — ein fehlender Schlüssel ist ein normaler Zustand, der im Voraus gemeldet wird, keine Ausnahme, die beim Klicken auf Senden geworfen wird.

Setze auf serverlosen Hosts NEXTJS_MCP_DATA_DIR=/tmp/nextjs-mcp-kit; deren Bundle-Dateisystem ist außer /tmp schreibgeschützt. Siehe Persistenz.

Routen

Statuscodes haben eine Bedeutung: 503, wenn ein Provider schlicht nicht verfügbar ist (die Anfrage war in Ordnung), 400 bei falscher Eingabe, 500 bei echtem Fehler.

curl -X POST localhost:3000/api/chat -H 'content-type: application/json' -d '{
  "provider": "ollama",
  "model": "llama3.1:8b",
  "system": "Answer in one word.",
  "messages": [{ "role": "user", "content": "Capital of France?" }]
}'
# {"answer":"Paris","provider":"ollama","model":"llama3.1:8b","billed":false}

Tools

/api/chat hat keine Tools und wird nie welche haben. Tool-Aufrufe sind eine eigene Route, die die Provider-Registry direkt aufruft — sie kapselt /api/chat nicht.

curl -X POST localhost:3000/api/agent-chat -H 'content-type: application/json' -d '{
  "provider": "anthropic",
  "model": "claude-haiku-4-5-20251001",
  "messages": [{ "role": "user", "content": "What is the refund window?" }],
  "tools": ["refund_policy"]
}'
# {"answer":"…","provider":"anthropic","model":"…","billed":true,
#  "trace":[{"name":"refund_policy","result":"…","isError":false,"ms":2}]}

trace ist der Grund, warum sich das lohnt: Eine Antwort, die ein Tool verwendet hat, kann es beweisen.

Füge "stream": true für NDJSON hinzu — ein JSON-Objekt pro Zeile, {"type":"token"} … {"type":"done"}. Lies es mit streamAgentChat aus nextjs-mcp-kit/client, anstatt es selbst zu parsen.

Welche Tools ausgeführt werden, liegt vollständig in der Wahl des Aufrufers: kein tools[] bedeutet ein einfacher Turn. Es wird nie etwas stillschweigend verworfen — ein Provider, der keine Tools aufrufen kann, oder ein Ollama-Modell ohne diese Fähigkeit erhält eine 503 mit dem Grund, statt einer Antwort, die das, worum du gebeten hast, still ignoriert.

Route-Segment-Konfiguration

Jede gescaffolte Route deklariert ihr eigenes runtime:

export { POST } from 'nextjs-mcp-kit/api/chat';

export const runtime = 'nodejs';
export const maxDuration = 120;

Das ist kein Boilerplate, das du weglassen kannst. Next liest die Segment-Konfiguration statisch aus dem Routenmodul selbst, daher wird ein re-exportiertes runtime still ignoriert und der Handler läuft auf dem falschen.

Einen Provider hinzufügen

Die Provider-Ebene ist die eine Stelle, die sich mit Modell-Backends auskennt. Zwei Schritte:

1. Schreibe einen ChatProvider:

import type { ChatProvider } from 'nextjs-mcp-kit/types';

export const myProvider: ChatProvider = {
  id: 'mine',
  label: 'My backend',
  defaultModel: 'some-model',
  billed: false,
  dynamicModels: false,

  // Never throws. A missing key or a down daemon is a normal state.
  async isAvailable() {
    return process.env.MY_KEY
      ? { available: true }
      : { available: false, reason: 'MY_KEY is not set' };
  },

  async listModels() {
    return [{ id: 'some-model', label: 'Some model' }];
  },

  // `system` arrives separately: Anthropic takes it as a top-level field,
  // Ollama as a message role. That difference is absorbed here, per provider.
  async chat({ model, system, messages }) {
    return { text: '…', model };
  },
};

2. Füge ihn zur Registry hinzu.

Sonst ändert sich nichts. Nicht die Route, nicht der Reducer, nicht der Picker, nicht eine Typ-Union — ProviderId ist absichtlich string. /api/providers und ProviderModelPicker werden von der Registry gesteuert, sodass ein neuer Provider in beiden Dropdowns mit null Client-seitigen Änderungen erscheint.

billed steuert das 💳/🖥️-Abzeichen. Ein kostenpflichtiger Turn darf nie eine Überraschung sein.

Damit dein Provider Tools aufrufen kann, füge das optionale chatWithTools hinzu. Es bleibt optional, sodass ein Provider ohne es weiterhin voll nutzbar ist — und als tool-unfähig gemeldet wird, statt still ohne die angeforderten Tools zu antworten:

async chatWithTools({ model, system, messages, tools, run, onToken }) {
  // `tools` is neutral — translate it with your dialect:
  //   import { DIALECTS } from 'nextjs-mcp-kit/tools';
  //   const declared = DIALECTS.openai.toTools(tools);
  // Then loop: ask, ingestToolCalls(raw), await run(call), feed results back.
  return { text: '…', model, trace: [] };
}

Die meisten neuen Backends sind OpenAI-kompatibel, und DIALECTS.openai existiert bereits — ein neuer Provider fügt also meist gar kein Dialekt hinzu.

Wie Tools unter der Haube funktionieren

Ein Tool wird einmal in einer neutralen Form gespeichert. Die Schreibweise jedes Providers wird davon abgeleitet:

import { deriveByProvider } from 'nextjs-mcp-kit/tools';

deriveByProvider(tools).anthropic; // [{ name, description, input_schema }]
deriveByProvider(tools).ollama;    // [{ type:'function', function:{ … } }]

Das ist wichtig, weil Anthropic und Ollama bei jedem Schritt unterschiedlicher Meinung sind — der Schema-Schlüssel, ob Aufrufe eine id tragen und wie Ergebnisse zurückgegeben werden. Zwei von Hand gepflegte Listen würden beim ersten Bearbeiten einer von beiden auseinanderdriften.

Zwei Arten, beide von Tag eins an aufrufbar:

skill ist, wie ein Dokument oder ein SKILL.md-förmiger Inhalt ohne Dateisystem zu einem Tool wird. Der Text ist ein Feld in einem Datensatz.

Das id-Problem und wie es gelöst wird. Anthropic gibt jedem Tool-Aufruf eine id und paart Ergebnisse über tool_use_id; Ollamas native API sendet überhaupt keine id und paart nach Reihenfolge. Eine einzelne Schleife, die das eine annimmt, bricht an dem anderen. Daher wird außerhalb einer Datei keine der beiden Annahmen getroffen: ingestToolCalls() behält die id, wo es eine gibt, erzeugt name#index, wo es keine gibt, und normalisiert Argumente, die als JSON-String angekommen sind. Nach dem Ingest sind die zwei Provider ununterscheidbar, und jeder gibt Ergebnisse weiterhin so zurück, wie es seine eigene API verlangt.

Die React-Teile liegen hinter eigenen Unterpfaden, sodass ihr Import keine Node-Built-ins – oder ANTHROPIC_API_KEY – in ein Client-Bundle ziehen kann. Wenn es rendert, ist es nicht im Root.

Unterpfade werden über die exports-Map in package.json aufgelöst, die "moduleResolution": "bundler" in deiner tsconfig.json benötigt. create-next-app setzt das bereits; bei der veralteten Einstellung "node" schlägt die Auflösung jedes Unterpfads mit Cannot find module 'nextjs-mcp-kit/components' fehl.

Zustand

Ein Context mit getrennten Werten: { state, actions }, konsumiert über useContextState() / useContextActions(). Komponenten, die nur dispatchen, werden bei unabhängigen Zustandsänderungen nicht neu gerendert.

'use client';
import { useContextState, useContextActions } from 'nextjs-mcp-kit/context';

function MyChat() {
  const { agent, instruction } = useContextState();
  const { sendChat, selectProvider } = useContextActions();
  // agent.chat, agent.provider, agent.model, agent.routing …
}

Zwei Slices, agent und instruction. Aktionen lesen den aktuellen Zustand über eine Ref statt über eine Closure, wodurch die Identität jeder Aktion über die Lebensdauer des Providers stabil bleibt – ohne das würde sendChat bei jedem Tastendruck neu erstellt.

Presets vs. systemText

Zwei verschiedene Dinge, und sie zu vermischen wäre ein Fehler:

• presets — die gespeicherte, persistierte Liste.

• systemText — der bearbeitbare Text, der tatsächlich mit der nächsten Runde gesendet wird.

Die Auswahl eines Presets befüllt systemText. Wenn du es danach bearbeitest, mutiert das das gespeicherte Preset nicht. Ein Preset ist ein Ausgangspunkt, kein Käfig. Das Speichern unter einem vorhandenen Namen bearbeitet dieses Preset (die id wird vom Namen abgeleitet), anstatt Fast-Duplikate anzuhäufen.

Theming

Alle Farben stammen aus CSS-Custom-Properties. Überschreibe jede davon nach dem Import – das ist die ganze Theming-Geschichte:

:root {
  --mcp-bubble-user: #dcfce7;
  --mcp-border: #cbd5e1;
}

Hell und Dunkel werden beide über prefers-color-scheme definiert.

Persistenz

Instruktions-Presets und Tools werden als JSON unter NEXTJS_MCP_DATA_DIR (Standard ./.data) gespeichert – das kleinste Etwas, das einen Neustart überlebt. Füge .data/ zu deiner .gitignore hinzu.

.data/
  instructions.json
  tools.json

Es ist ein Datei-Store, also ist es auf Serverless pro Instanz und ephemer – das Bundle-Dateisystem ist außer /tmp schreibgeschützt, und /tmp wird zwischen Aufrufen geleert. Wenn du Dauerhaftigkeit brauchst, ersetze zwei Dateien: src/store/instructions.ts und src/store/tools.ts sind die einzigen Stellen, an denen die Routen lesen oder schreiben.

Der Inhalt eines Skills ist ein Feld in einem Tool-Datensatz, keine Datei auf der Festplatte. Das Hochladen eines Dokuments erzeugt nirgendwo eine SKILL.md, und nichts in diesem Paket schreibt jemals in den Quellbaum deiner App.

Verbinden eines MCP-Clients

{
  "mcpServers": {
    "nextjs-mcp-kit-local": {
      "type": "http",
      "url": "http://localhost:3000/api/mcpserver/mcp"
    }
  }
}

Beachte das Suffix /mcp – die Route ist ein dynamisches [transport]-Segment, daher reicht es nicht, einen Client nur auf /api/mcpserver zu richten.

Dieser Endpunkt ist eine öffentliche Schnittstelle, keine private Tür. Stelle deine App bereit, und jeder kann seinen eigenen MCP-Client mit seinem eigenen Modell und seinem eigenen Schlüssel auf https://your-app.example.com/api/mcpserver/mcp richten – es gibt nichts von dir, das sie haben könnten. Sie bekommen jeden Prompt und jedes Tool, das du hinzugefügt hast, und /mcp-dashboard zeigt genau, was das ist.

Was dies bewusst nicht tut

• Keine Tools in /chat. Diese Route sendet absichtlich nur Nachrichten und sonst nichts. Tools leben auf /api/agent-chat und den vier Seiten oben.

• Kein Streaming auf /api/chat. Seine Antworten kommen vollständig an, und seine Form hat sich nicht geändert. /api/agent-chat streamt.

• Keine Authentifizierung. Binde diese Routen hinter deiner eigenen ein. Beachte, dass /api/mcpserver/mcp von Design aus öffentlich ist – es ist dafür gedacht, angesteuert zu werden.

• Kein .docx- oder .pdf-Upload. Nur .md und .txt, weil die Unterstützung null Abhängigkeiten zu einem Paket hinzufügt, das du installierst. Ein Format hinzuzufügen ist ein Zweig in src/server/extractText.ts.

• Keine Datenbank. Tools und Presets sind JSON-Dateien. Auf Serverless ist das pro Instanz und ephemer – tausche die beiden Store-Dateien.

• Nichts vorgebaut „für später“. Keine Platzhalter-Registries, keine toten Abstraktionen.

Anforderungen

Next.js ≥ 16 (App Router), React ≥ 18.3, Node ≥ 20.9. Getestet mit Next 16.2 und React 19.2.

Ein Hinweis

Die nextjs-mcp-kit-Architektur implementiert eine strikte Grenze, die öffentliche clientseitige Komponenten von sicherer serverseitiger Ausführung trennt. Die React-basierte Client-Schicht koordiniert interaktive Zustände und Chat-Oberflächen, arbeitet aber völlig blind gegenüber sensiblen Umgebungsvariablen oder Anmeldedaten Dritter. Die Sicherheit wird gewahrt, weil alle API-Schlüssel, lokalen Tool-Ausführungen und direkten LLM-Aufrufe ausschließlich hinter Next.js-Route-Handlern in einer sicheren Node.js-Laufzeitumgebung liegen. Die Kommunikation zwischen diesen Grenzen ist um standardmäßige HTTP-POST-Aktionen für benutzerinitiierte Ereignisse und Server-Sent Events (SSE) für unidirektionales Echtzeit-Datenstreaming strukturiert. Dieses Setup stellt sicher, dass komplexe Multi-Agenten-Workflows hochreaktiv bleiben und gleichzeitig strengen modernen Enterprise-Sicherheitsrichtlinien entsprechen.

Die nextjs-mcp-kit-Architektur implementiert eine strikte Grenze, die öffentliche clientseitige Komponenten von sicherer serverseitiger Ausführung trennt. Die React-basierte Client-Schicht koordiniert interaktive Zustände und Chat-Oberflächen, arbeitet aber völlig blind gegenüber sensiblen Umgebungsvariablen oder Anmeldedaten Dritter. Die Sicherheit wird gewahrt, weil alle API-Schlüssel, lokalen Tool-Ausführungen und direkten LLM-Aufrufe ausschließlich hinter Next.js-Route-Handlern in einer sicheren Node.js-Laufzeitumgebung liegen. Die Kommunikation zwischen diesen Grenzen ist um standardmäßige HTTP-POST-Aktionen für benutzerinitiierte Ereignisse und Server-Sent Events (SSE) für unidirektionales Echtzeit-Datenstreaming strukturiert. Dieses Setup stellt sicher, dass komplexe Multi-Agenten-Workflows hochreaktiv bleiben und gleichzeitig strengen modernen Enterprise-Sicherheitsrichtlinien entsprechen.

Das Interessante an diesem Paket ist, wie wenig deiner Zeit es in Anspruch nimmt.

Alles, was normalerweise die Arbeit ist – die Provider-Naht, die Tool-Calling-Schleife, die zwei Provider, die sich darüber uneinig sind, wie Tools deklariert werden und wie Ergebnisse zurückkommen, das Streaming, der MCP-Server, die Persistenz – ist erledigt. Installiert, nicht kopiert. Es bleibt erledigt, wenn du npm update ausführst, und nichts davon ist Code, den du lesen, besitzen oder warten musst.

Was für dich übrig bleibt, ist der einzige Teil, der je wirklich dir gehörte: zu entscheiden, was dein Chat wissen soll. Das ist ein Name, ein Satz, der beschreibt, wann man es verwendet, und die Antwort. Geschrieben in ein Formular, in einem Browser, in unter einer Minute. Zehn davon, und du hast einen Chat, der deine App besser kennt als jeder Allzweck-Assistent es je tun wird – denn niemand sonst hat deine Öffnungszeiten, dein Rückgabefenster oder deine Versandregeln.

Die Form der Arbeit ist also ungewöhnlich: ein Nachmittag, und der größte Teil davon damit verbracht, darüber nachzudenken, was deine Besucher tatsächlich fragen, statt über Tool-Schemas und Provider-APIs. Die Demo ist schnell gebaut und überproportional gut vorzeigbar, weil das, was die Leute beeindruckend finden – es wusste das über deine App – von dem Teil kommt, der eine Minute gedauert hat, nicht von dem Teil, der Monate gedauert hat.

Zwei Dinge sind wissenswert, bevor du beginnst, damit hier nichts überverkauft wird. Dies ist ein fokussierter Chat von Design: Er ist sehr gut darin, aus dem zu antworten, was du ihm gegeben hast, und er versucht nicht, ein Allzweck-Assistent zu sein. Und es gibt keine Authentifizierung irgendwo in diesem Paket – /add-tool und /mcp-dashboard gehören dir, nicht deinen Besuchern. Setze sie hinter deine eigene Authentifizierung oder binde sie gar nicht erst in die öffentliche App ein.

Abgesehen davon: Geh und bau etwas damit. Es wurde geschrieben, um erweitert zu werden, nicht nur bewundert: Ein neuer Provider ist eine Datei und ein Array-Eintrag, eine neue Tool-Art ist ein Zweig, und der Store sind zwei Dateien, die man gegen eine echte Datenbank austauschen kann. Wenn du etwas damit machst, würde ich es wirklich gerne sehen.

Danke ❤️

Dieses Kit ist ein dünnes Ding, das auf der substanziellen Arbeit anderer Leute sitzt.

Ollama ❤️ – dafür, dass lokale Modelle wirklich einfach sind. Kein Konto, kein Schlüssel, keine Rechnung: Ein Modell ziehen, und es antwortet. Das ist der einzige Grund, warum nextjs-mcp-kit in dem Moment nützlich sein kann, in dem du es installierst, und warum der Standard-Provider der lokale ist.

Claude und Anthropic ❤️ — für die Modelle und für das Model Context Protocol. MCP ist das, worauf die /-Route aufbaut, und es wurde als offene Spezifikation verschenkt, statt als Burggraben behalten zu werden. Dieses Paket würde ohne es in dieser Form nicht existieren.

Beide Anbieter sind hier bewusst erstklassig. Einer ist lokal und kostenlos, einer ist gehostet und exzellent, und die Anbieter-Nahtstelle existiert, damit keiner gewinnen muss.

Lizenz

MIT