ask-me-mcp

Ein Persona-MCP-Server. Frag Claude / ChatGPT / Grok nach der Arbeit des Betreibers, seinen Patterns, seiner Verfügbarkeit und seinem Angebot – basierend auf seinem öffentlichen Lebenslauf, Projektindex und der Angebotsseite.

Referenzimplementierung des MCP-Server-Harness-Musters. Dieses Repo ist ein funktionierendes Beispiel derselben Architektur, die der Betreiber als produktisiertes 6-Wochen-Engagement verkauft. Wenn dir die Form gefällt, ist genau das das Verkaufsargument – siehe Das Muster unten.

Was es tut

Sechs typisierte Tools, die jeder Benutzer eines KI-Assistenten aufrufen kann:

Jede Antwort enthält ein Konfidenzlabel und eine Quellenangabe. Der Server erfindet nichts; wenn die Grounding-Daten es nicht hergeben, sagt der Server es nicht.

Related MCP server: Internal Data MCP Server

Installation (als Benutzer)

Der Remote-Endpoint nutzt MCP Streamable HTTP + OAuth 2.1. Es gibt drei Verbindungsmöglichkeiten:

1. Claude Desktop — Connector-Verzeichnis (Schaltfläche "Connect")

Füge über die Claude-Desktop-Benutzeroberfläche hinzu: Settings → Connectors → Add custom connector → URL: https://ask-me-mcp-xi.vercel.app/api/mcp. Klicke auf Connect. Der Desktop-Client erkennt OAuth-Metadaten, registriert sich als Client, tauscht Tokens aus und bindet die Tools ein. Keine manuelle Konfiguration erforderlich.

2. Claude Desktop / Claude Code — Konfigurationsdatei (OAuth überspringen)

Füge zu claude_desktop_config.json hinzu – der Speicherort variiert je nach Betriebssystem; siehe Claude-Desktop-Konfigurationsdokumentation:

{
  "mcpServers": {
    "ask-me": {
      "url": "https://ask-me-mcp-xi.vercel.app/api/mcp"
    }
  }
}

3. Claude Code CLI

claude mcp add --scope user ask-me https://ask-me-mcp-xi.vercel.app/api/mcp

Lokaler Stdio-Modus (Entwicklung)

Für die lokale Stdio-Entwicklung (kein HTTP, kein OAuth – Authentifizierung gilt nicht für stdio):

{
  "mcpServers": {
    "ask-me": {
      "command": "node",
      "args": ["/absolute/path/to/ask-me-mcp/dist/src/server.js"]
    }
  }
}

Danach in einer beliebigen Claude-Code-Sitzung:

Worauf liegt Ilyes' aktueller Fokus? Welche Patterns hat er für die LLM-Evaluierung entwickelt? Ist er im Oktober für ein Playbook-Engagement verfügbar?

Entwicklung (als Maintainer)

Voraussetzungen

• Node.js 20+

• npm (oder pnpm / yarn – package.json ist npm-first)

Einrichtung

git clone https://github.com/tounsils/ask-me-mcp.git
cd ask-me-mcp
npm install

Lokal als Stdio-Server ausführen

npm run dev

Richte Claude Code oder den MCP Inspector auf den resultierenden Prozess aus.

Für die Produktion bauen

npm run build

Ausgabe nach dist/.

Auf Vercel bereitstellen

# Set the JWT signing secret (one-time; required for OAuth).
vercel env add MCP_JWT_SECRET production
# Paste a long random string. Generate one: `openssl rand -base64 48`.

vercel deploy --prod

Der api/mcp.ts-Handler bedient den Streamable-HTTP-Transport mit OAuth-2.1-Schutz – das Format, das sowohl das Connector-Verzeichnis von Claude als auch das Apps SDK von ChatGPT verwenden. Die vollständige Architektur findest du in docs/oauth-flow.md.

Das Evaluierungskorpus ausführen

npm run eval           # 15 tool cases against handlers directly (no HTTP)
npm run eval:oauth     # 6-step end-to-end OAuth flow (needs MCP_JWT_SECRET)

Das Tool-Korpus lässt den Build fehlschlagen, wenn weniger als ein Schwellenwert-Prozentsatz der erwarteten Antworten übereinstimmt. Bestanden oder nichts wird ausgeliefert.

Der OAuth-Flow-Test übt Register → Authorize → Token → geschütztes /api/mcp → 401-Challenge → Refresh – alles prozessintern gegen Vercel-förmige Mock-Request/Response-Objekte.

Repository-Struktur

ask-me-mcp/
├── src/
│   ├── server.ts               # shared MCP server (used by both stdio + HTTP)
│   ├── tools/                  # six typed tool implementations
│   │   ├── getCurrentFocus.ts
│   │   ├── getEngagementSummary.ts
│   │   ├── searchReusablePatterns.ts
│   │   ├── checkAvailability.ts
│   │   ├── getOfferDetails.ts
│   │   └── bookDiscoveryCall.ts
│   ├── grounding/
│   │   ├── data.json           # pre-extracted structured facts (v0)
│   │   └── index.ts            # loaders + search helpers
│   └── rails/
│       └── confidence.ts       # confidence + source-citation wrapper; refusal helper
│   └── oauth/                  # OAuth 2.1 + PKCE + anonymous DCR
│       ├── config.ts           # issuer, scopes, TTLs, endpoint paths
│       ├── jwt.ts              # HS256 sign/verify (via `jose`)
│       ├── clientRegistry.ts   # client_id = signed JWT (no DB)
│       └── codeGrant.ts        # auth code + access/refresh token + PKCE S256
├── api/
│   ├── mcp.ts                          # Vercel serverless entry (Streamable HTTP + Bearer auth)
│   ├── health.ts                       # diagnostic (unauthenticated)
│   ├── register.ts                     # RFC 7591 DCR
│   ├── authorize.ts                    # authorization endpoint (auto-approves)
│   ├── token.ts                        # token exchange with PKCE
│   ├── oauth-protected-resource.ts     # RFC 9728 metadata
│   └── oauth-authorization-server.ts   # RFC 8414 metadata
├── eval/
│   ├── corpus.json             # 15 tool cases + expected answers
│   ├── runner.ts               # replays tool corpus, threshold-gated
│   └── oauth-flow.ts           # 6-step OAuth end-to-end test
├── docs/
│   └── oauth-flow.md           # OAuth architecture + how to swap for real user identity
├── package.json
├── tsconfig.json
├── vercel.json
└── README.md

Das Muster: der MCP-Server-Harness

Dieses Projekt ist eine Referenzimplementierung eines Musters, das der Betreiber Kunden als produktisiertes 6-Wochen-Engagement ausliefert – das MCP-Server Product Playbook.

Die Form:

1. Typisierter Tool-Vertrag. Sechs Tools mit striktem JSON-Schema. Nichts Freiform. Das Modell kann nur diese aufrufen, und nur mit diesen Argumenten.

2. Koordinator + Spezialisten (erweiterbar). v0 hat einen Koordinator (den MCP-Server, der Tool-Aufrufe weiterleitet). v1 wird Elicitation- und Supervisor-Agenten innerhalb komplexerer Tools hinzufügen.

3. Typisierter Signalvektor. Strukturierte Fakten, die aus den Grounding-Daten extrahiert werden. Kein Freitext.

4. Versionierte Reasoning-Spezifikation. Die Tool-Implementierungen SIND die Reasoning-Spezifikation – im Code versioniert, nicht in einem Prompt.

5. Leitplanken + Konfidenz. Jede Antwort enthält confidence + sources + optional disclaimers. Das Modell kann sie anzeigen.

6. Externes Grounding. Der Server fragt src/grounding/data.json ab; das Modell erfindet nie etwas.

7. Evaluierungskorpus + Eval-Runner + Zertifizierung. eval/corpus.json enthält erwartete Antworten; npm run eval spielt sie ab. Wird ausgeliefert oder nicht.

Wenn du ein Produkt baust, das in diese Form passt (Karriereberatung, medizinische Triage, rechtliche Ersteinschätzung, Finanzplanung, Coaching, Expertensystem – was auch immer), verkauft der Betreiber ein 6-Wochen-Engagement mit festem Umfang, um es auszuliefern. Siehe get_offer_details oder schreibe eine E-Mail an tounsils@gmail.com.

Lizenz

MIT. Siehe LICENSE.

Namensnennung

Erstellt von Ilyes Tounsi · Carlsbad, CA · tounsils.github.io.