Skip to main content
Glama
Schubeler-Consulting

knowmind

by Schubeler-Consulting
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

knowmind

Ihr KI-Assistent kennt Ihr Unternehmen nicht. Er beginnt jedes Gespräch bei null, und Sie erklären ihm zum wiederholten Mal dieselben Zusammenhänge. knowmind ist das Gedächtnis darunter: Was Sie einmal ablegen, steht in Claude, ChatGPT, Cursor und Ihren eigenen Anwendungen zur Verfügung. Betrieben in Deutschland, im Rechenzentrum Nürnberg.

Der Privat-Tarif kostet dauerhaft nichts und verlangt keine Zahlungsdaten. Schnittstelle, Kommandozeile und MCP-Server sind in jedem Tarif enthalten, auch dort.

npm · knowmind.de · Discord · dieses Paket unter Apache-2.0

Installation

npm install -g knowmind

Oder ohne Installation direkt als MCP-Server: npx -y knowmind mcp

Related MCP server: Memory Nexus MCP

Einrichtung

  1. Kostenloses Konto auf knowmind.de anlegen und dort einen Zugangsschlüssel erzeugen: Dashboard → API-Tokens

  2. Lokal speichern:

knowmind login --token kmt_xxxxxxxx

Alternativ über ENV:

export KNOWMIND_TOKEN=kmt_xxxxxxxx
export KNOWMIND_API_URL=https://knowmind.de

Befehle

npx -y knowmind install <ide>       MCP-Server im KI-Client verdrahten (claude, cursor, vscode …)
knowmind init                       Automatische Gedächtnis-Pflege im KI-Client einrichten
knowmind search "Wo läuft die OKR-App?"
knowmind upload notizen.md --title "Meeting Notizen 2026-05-12"
knowmind stats
knowmind health
knowmind status                     Lebenszeichen des Gedächtnisses (Report)
knowmind status --line              Einzeilige Statusline für Ihr KI-Werkzeug
knowmind config

Die Statusline (knowmind status --line) zeigt knowmind als grüne Lampe direkt in Ihrem KI-Werkzeug: ruhig grün, wenn erreichbar, grünes Flackern wie eine Festplatten-LED, während knowmind arbeitet, rot bei Ausfall. knowmind init --client claude-code bindet sie automatisch ein (eine bereits vorhandene eigene Statusline bleibt unangetastet).

Automatische Pflege einrichten (knowmind init)

Damit Ihre KI knowmind selbsttätig pflegt — Recall vor jeder Aufgabe, Sichern nach jeder sicherungswürdigen Runde — richtet knowmind init die passenden Mechanismen für Ihren Client ein. Der Befehl erkennt den Client am Projekt- und Home-Verzeichnis (.claude/, .cursor/, ~/.codex/) oder Sie wählen ihn explizit.

knowmind init                          # Client automatisch erkennen
knowmind init --client claude-code     # gezielt für Claude Code
knowmind init --client cursor          # gezielt für Cursor
knowmind init --dry-run                # zeigt nur, was geschähe (schreibt nichts)

Was eingerichtet wird:

  • Claude Code — projektlokale Hooks in .claude/:

    • UserPromptSubmit → ruft vor jeder inhaltlichen Frage knowmind_recall auf und reicht die Top-Treffer als Kontext nach (Memory-First, automatisch).

    • Stop → erinnert die KI daran, mit knowmind_store_memory zu sichern, wenn die Runde Sicherungswürdiges enthielt (Deploy/Commit, neue Regel, Entscheidung) und noch nichts gespeichert wurde.

    • ein Memory-First-Block in ./CLAUDE.md (mit <!-- BEGIN/END knowmind -->-Markern).

  • Cursor — .cursor/rules/knowmind.mdc mit der Memory-First-Regel (alwaysApply).

  • Claude Desktop / Codex / generisch — kein automatischer Hook-Mechanismus vorhanden; der Befehl zeigt den Memory-First-Text zum manuellen Einfügen (siehe Grenze unten).

Idempotent & nicht-destruktiv: Ein zweiter Lauf erzeugt keine Duplikate (marker-/befehls-basierte Ersetzung); bestehende fremde Dateien und Hooks bleiben unangetastet. Mit --dry-run sehen Sie jede Aktion vorab.

Grenze der Automatik: Eine harte Erzwingung der Pflege gibt es nur in Clients mit Hook-/Rule-Mechanismus (Claude Code, Cursor). In Clients ohne solchen Mechanismus (z. B. Claude Desktop, Codex CLI) greifen die MCP-instructions (werden beim Verbinden gelesen) und die MCP-prompts — eine modellabhängige Steuerung ohne technische Garantie.

MCP-Server einrichten

knowmind ist ein MCP-Server (npx -y knowmind mcp, stdio). Token aus dem knowmind.de-Dashboard (→ API-Tokens) als KNOWMIND_TOKEN; optional KNOWMIND_API_URL (Standard https://knowmind.de).

Claude Code

claude mcp add knowmind --env KNOWMIND_TOKEN=kmt_xxx --env KNOWMIND_API_URL=https://knowmind.de -- npx -y knowmind mcp

Claude Desktop / Cursor / Windsurf / Cline / Continue / Goose / Zed (claude_desktop_config.json, ~/.cursor/mcp.json, …)

{
  "mcpServers": {
    "knowmind": {
      "command": "npx",
      "args": ["-y", "knowmind", "mcp"],
      "env": { "KNOWMIND_TOKEN": "kmt_xxx", "KNOWMIND_API_URL": "https://knowmind.de" }
    }
  }
}

Windows-Hinweis: falls npx nicht direkt startet, "command": "cmd", "args": ["/c", "npx", "-y", "knowmind", "mcp"].

VS Code / GitHub Copilot (.vscode/mcp.json — Top-Level servers + inputs)

{
  "inputs": [{ "id": "knowmind_token", "type": "promptString", "description": "Knowmind API token", "password": true }],
  "servers": {
    "knowmind": {
      "command": "npx",
      "args": ["-y", "knowmind", "mcp"],
      "env": { "KNOWMIND_TOKEN": "${input:knowmind_token}", "KNOWMIND_API_URL": "https://knowmind.de" }
    }
  }
}

Codex CLI (~/.codex/config.toml)

[mcp_servers.knowmind]
command = "npx"
args = ["-y", "knowmind", "mcp"]
env = { KNOWMIND_TOKEN = "kmt_xxx", KNOWMIND_API_URL = "https://knowmind.de" }

Gemini CLI (~/.gemini/settings.json) — gleiche mcpServers-Struktur wie Claude Desktop.

Remote (ohne lokale Installation) — für Clients mit HTTP-MCP-Support direkt der gehostete Endpoint:

{ "type": "http", "url": "https://knowmind.de/api/mcp/v1", "headers": { "Authorization": "Bearer kmt_xxx" } }

Token kann statt per env auch lokal via knowmind login --token kmt_xxx (→ ~/.knowmind/config.json) hinterlegt werden.

Tools (im MCP-Modus)

Der MCP-Modus ist seit 0.1.18 ein reiner Proxy auf die Plattform: Tool-Namen, Schemas und Safety-Annotations kommen direkt vom Server und sind damit immer identisch mit dem Remote-Connector (https://knowmind.de/api/mcp/v1).

  • knowmind_recall — Hybride Suche im Wissensspeicher des Mandanten

  • knowmind_recall_at_time — Recall mit Zeitfilter (bi-temporal)

  • knowmind_store_memory — Neue Erinnerung anlegen (Titel + Inhalt)

  • knowmind_upload_document — Längeren Text als Dokument ingestieren (Upsert-per-Titel: gleicher Titel ersetzt die alte Version)

  • knowmind_update_fact — Fakt bi-temporal aktualisieren (Historie bleibt)

  • knowmind_link — Typisierte Beziehung anlegen (Inverse wird automatisch gesetzt)

  • knowmind_unlink — Beziehung wieder entfernen (samt Inverse)

  • knowmind_list_relations — Beziehungen einer Erinnerung auflisten

  • knowmind_list_recent — Zuletzt angelegte Dokumente/Memories des Mandanten auflisten, sortiert nach Anlagedatum absteigend

  • knowmind_stats — Statistik über gespeicherte Erinnerungen und Beziehungen

  • knowmind_health — Verfügbarkeits-Status der Plattform

Inverse-Beziehungen (z. B. IS_EMPLOYEE_OF zu HAS_EMPLOYEE) werden serverseitig automatisch mit angelegt. Hinweis: knowmind upload als CLI-Befehl läuft über die REST-Schnittstelle (/api/documents), nicht über MCP.

Daten in Deutschland

knowmind wird in Deutschland betrieben: Ihre Inhalte (Memories, Account- und Metadaten) werden ausschließlich auf Servern in Deutschland (Hetzner-Rechenzentrum) gespeichert und verlassen Deutschland nicht. Auftragsverarbeitung (AVV) nach Art. 28 DSGVO verfügbar: https://knowmind.de/legal/avv

Hinweis (Bring-your-own-Key): Wenn Sie eigene Schlüssel externer KI-Anbieter hinterlegen, werden Ihre Anfragen direkt an den von Ihnen gewählten Anbieter übermittelt. Sitzt dieser außerhalb der EU, kann dabei ein Drittlandtransfer stattfinden, für den Sie als Verantwortlicher zuständig sind.

Haftung & Nutzung (Disclaimer)

  • Software: Dieses Paket steht unter der Apache-Lizenz 2.0 und wird „AS IS" ohne jegliche Gewährleistung bereitgestellt; die Haftung ist im Rahmen der Lizenz (Abschnitte 7 und 8) ausgeschlossen bzw. beschränkt. Siehe LICENSE.

  • Eigenes Konto, eigener Token: knowmind bündelt keine Zugangsdaten. Sie nutzen Ihren eigenen knowmind.de-Account und API-Token. Anlegen: https://knowmind.de/dashboard/api-tokens

  • Eigene Kosten/Verbrauch: Jede Nutzung (API-Anfragen, Token-/Kontingentverbrauch, ggf. modellbezogene Kosten) erfolgt über Ihren eigenen Account und auf Ihre Verantwortung. Verbrauch und Kosten sind im knowmind.de-Dashboard transparent einsehbar.

  • Service-Bedingungen: Für die Nutzung der gehosteten Plattform gelten die AGB und die Datenschutzerklärung von knowmind.de: AGB · Datenschutz · AVV · Impressum

  • Kein Einsatz in sicherheitskritischen Bereichen: knowmind ist ein Gedächtnis-/Recall-Dienst und nicht für den Betrieb von selbstfahrenden Fahrzeugen, kritischer Infrastruktur, medizinischen oder lebenserhaltenden Systemen oder sonstigen Anwendungen bestimmt, bei denen ein Fehler oder Ausfall zu Tod, Personen-, Umwelt- oder schweren Sachschäden führen kann. Ein Einsatz in solchen Umgebungen erfolgt auf alleiniges Risiko des Nutzers.

Anbieter: Schübeler Consulting — Johann Jörgen Schübeler. Kontakt: info@schuebeler-consulting.de

Available Tools

7 tools
knowmind_list_recentA
Read-onlyIdempotent

Listet die zuletzt angelegten Dokumente/Memories des Tenant-Korpus, sortiert nach Anlagedatum absteigend (created_at). Quelle ist der Dokument-Korpus — dieselbe Basis, die der Recall durchsucht. Graph-Entitäten ohne Zeitstempel erscheinen nicht; die Anzahl weicht darum bewusst von stats.memories ab. Scope read genügt.

ParametersJSON Schema
NameRequiredDescriptionDefault
kNoAnzahl der neuesten Einträge (1–50)

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description adds that scope 'read' suffices, sorting order, and the exclusion of graph entities without timestamps, which is useful beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load purpose, each sentence adds value: purpose, source, limitation. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, no output schema, and strong annotations, the description covers source, scope, sorting, and limitations. Complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'k' with 100% schema description coverage (min, max, default). Description does not add additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'list the most recently created documents/memories' with specific sorting by created_at descending, distinguishing from siblings like knowmind_list_relations and knowmind_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the source corpus and relationship to recall, and notes that untimestamped entities are excluded, causing discrepancy with stats. However, no explicit when-not or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowmind_list_relationsA
Read-onlyIdempotent

Liefert alle Beziehungen einer Memory (eingehend + ausgehend) mit Edge-Typ und Ziel-/Quellknoten. Scope read genügt.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idYesMemory-ID, deren Beziehungen abgefragt werden

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by specifying that both incoming and outgoing relations are returned, along with edge type and target/source node. It also confirms read-only nature aligns with readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler, front-loaded with the verb and resource. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers basic behavior and return fields but omits details like handling of missing memory IDs, pagination (if any), or additional response structure. Given no output schema, more detail would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes the parameter fully. The description does not add any additional meaning beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns all relations (incoming+outgoing) of a memory with edge type and node info. It distinguishes from sibling tools like knowmind_link (linking) and knowmind_unlink (unlinking), but could be more explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. The note 'Scope read genügt' hints at permission requirements but does not provide when-to-use or when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowmind_statsA
Read-onlyIdempotent

Aktuelle Statistik des Tenant-Korpus: Memories, Edges, Chunks.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that the stats cover Memories, Edges, and Chunks, providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately conveys the purpose and scope. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters or output schema, the description explains what the tool does and what it covers. It could mention if the stats are real-time or aggregated, but it is sufficiently complete for a simple stat tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter meaning, and it sufficiently describes what the tool returns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies 'Aktuelle Statistik des Tenant-Korpus: Memories, Edges, Chunks', which clearly states the verb (returns statistics), resource (tenant corpus), and scope (Memories, Edges, Chunks). This distinguishes it from sibling tools like knowmind_store_memory or knowmind_upload_document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives are given. However, context signals (no parameters, readOnlyHint) imply it is for getting an overview. The sibling list provides indirect differentiation, but no direct guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowmind_store_memoryA

Speichere dauerhafte Erkenntnisse unaufgefordert, sobald sie entstehen — Entscheidungen, Vorlieben, Fakten, Ergebnisse, Termine. Legt einen Memory-Eintrag dauerhaft im Tenant-Korpus an (Postgres + Vektor-Index + Graph-Knoten) — danach per knowmind_recall und knowmind_list_recent auffindbar. Append-only: gleicher Titel ersetzt NICHTS (dafür knowmind_update_fact); sha-identischer Inhalt wird idempotent erkannt (unchanged). Liefert die Memory-ID zurück. Scope write erforderlich.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoSchlagworte für Filterung
titleNoKurz-Titel des Memory-Eintrags
sourceNoQuelle/Herkunft, frei-text
contentYesVolltext des Memory-Eintrags
memory_typeNosemantic

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses append-only nature, idempotent detection for hashed content, multi-store persistence (Postgres, vector index, graph), and required scope. Adds context beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a focused single paragraph front-loading the 'what', with no filler. Could be slightly more structured but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, behavior, return value, and required scope. Lacks error handling details but sufficient for a memory-storage tool given schema richness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (80%+), so description adds limited extra meaning. It mentions append-only and idempotency but duplicates schema info for most parameters. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Speichere') and resource ('Erkenntnisse') and explicitly distinguishes from siblings like knowmind_update_fact for updates and knowmind_recall for retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use ('sobald sie entstehen') and when not ('gleicher Titel ersetzt NICHTS, dafür knowmind_update_fact'), with explicit alternatives and idempotency behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowmind_upload_documentA

Ingestet einen längeren Text dauerhaft als Dokument in den Tenant-Korpus: Chunk-Splitter, Embeddings, Vector-Chunks, Graph-Knoten. Upsert-per-Titel: existiert ein Dokument gleichen Titels, ersetzt die neue Version die alte (Server-Default, wie /api/documents). Scope write erforderlich.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDokument-Titel
sourceNoQuelle, z.B. URL oder Dateipfad
contentYesVolltext des Dokuments

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (non-readonly, non-destructive), the description discloses that it performs chunking, embedding, upsert behavior, and requires write scope. This adds significant behavioral context not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long and front-loads the main action and processing steps. It is reasonably concise, though the first sentence could be slightly shorter. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the input requirements and behavior (upsert, processing). It could mention success/return value, but overall it provides sufficient context for a 3-parameter tool with full schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with per-parameter descriptions. The tool description does not add additional meaning to the parameters beyond what the schema already provides, justifying a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Ingestet' and resource 'Dokument' clearly indicate the action of uploading a document. It distinguishes from sibling tools (linking, listing, etc.) by describing the ingestion process (chunking, embeddings). However, it could be more explicit about the primary use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that write scope is required and that it performs an upsert by title, but it does not explicitly state when to use this tool versus alternatives. The context implies it's for persisting documents, but no direct guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv0.3.1
    • First observedknowmind_link
    • First observedknowmind_list_recent
    • First observedknowmind_list_relations
    • First observedknowmind_stats
    • First observedknowmind_store_memory
    • First observedknowmind_unlink
    • First observedknowmind_upload_document
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a distinct purpose: linking, listing recent, listing relations, stats, storing memories, unlinking, and uploading documents. No overlap in functionality.

Naming Consistency4/5

All tools use the 'knowmind_' prefix and mostly snake_case verb_noun pattern, though 'stats' is a noun and 'list_recent' includes an adjective, which are minor deviations.

Tool Count5/5

7 tools is appropriate for a knowledge management system, covering core operations without being excessive or insufficient.

Completeness2/5

Missing critical tools like recall/search, update memory, and delete memory. References to 'knowmind_update_fact' and 'knowmind_recall' indicate gaps that hinder full lifecycle management.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Schubeler-Consulting/knowmind'

If you have feedback or need assistance with the MCP directory API, please join our Discord server