knowmind

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
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.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 47 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations zeigen idempotentHint=true und destructiveHint=false. Die Beschreibung ergänzt: 'Inverse Edges werden automatisch materialisiert', was über die Annotationen hinausgeht. Sie erwähnt außerdem die erforderliche Berechtigung (Scope write). Kein Widerspruch zu Annotationen.
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?
Die Beschreibung ist als Absatz formuliert mit wichtigen Informationen vorn. Sie könnte strukturierter sein (z.B. Aufzählung), aber sie ist prägnant und ohne unnötige Wiederholungen. Jeder Satz trägt zur Nutzbarkeit bei.
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?
Angesichts der Komplexität (verschiedene Kantentypen, 4 Parameter, kein Ausgabe-Schema) deckt die Beschreibung die wesentlichen Aspekte ab: Zweck, Typen, Einschränkungen, Verhalten inverser Kanten und Autorisierung. Es fehlen Details zu Fehlerbedingungen (z.B. wenn Knoten nicht existieren), aber insgesamt ist es ausreichend vollständig.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Die Schema-Abdeckung beträgt 100%, aber die Beschreibung fügt bedeutende Semantik hinzu: eine Liste erlaubter rel_type-Werte, explizites Verbot generischer Kanten und die Angabe des Standardwerts für confidence (1.0 für gepflegte Kanten). Dies geht weit über die Schema-Beschreibungen hinaus.
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?
Die Beschreibung gibt klar an, dass das Werkzeug eine typisierte Beziehung zwischen zwei Memory-Knoten erstellt. Sie listet explizit erlaubte rel_type-Werte auf und verbietet generische Kanten, wodurch es sich von Geschwistern wie 'knowmind_unlink' (zum Löschen) und 'knowmind_store_memory' (zum Speichern von Knoten) unterscheidet.
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?
Die Beschreibung gibt klare Hinweise zur Verwendung: Erstellen von typisierten Kanten, Verbot generischer Kanten, und erforderlicher Schreibbereich. Sie gibt keine expliziten Alternativen an (wie 'verwende knowmind_unlink zum Entfernen'), aber der Kontext ist ausreichend.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds value by stating that the inverse edge is also deleted, which is behavioral insight beyond the annotations. It also notes the scope requirement, enhancing transparency. No contradictions with 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 two sentences, each adding essential information: the primary action and a key behavioral detail (inverse edge deletion). No redundancy or unnecessary words. Front-loaded with the core purpose.
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 delete operation with three parameters, the description covers the necessary information: action, resource, side effect (inverse edge deletion), and required scope. No output schema is needed. The description is complete given the tool's complexity.
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 description coverage is 100% with clear parameter descriptions in the schema (e.g., 'Memory-ID des Zielknotens'). The tool description does not add extra semantic information beyond what is already in the schema. The baseline of 3 is appropriate as the schema does the heavy lifting.
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 clearly states it deletes a typed relationship between two memory nodes, with the verb 'Löscht' and explicit mention of the resource. It also notes that the inverse edge is also deleted, providing clarity on the operation's scope. This distinguishes it from the sibling tool 'knowmind_link' which creates relationships.
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?
The description mentions the prerequisite 'Scope write erforderlich' (scope write required), implying when to use (when write access is available). While it does not explicitly contrast with alternatives, the sibling tool 'knowmind_link' suggests that this tool is for removal. A more explicit 'use this to remove a relationship, not to create one' would be better, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![knowmind MCP server](https://glama.ai/mcp/servers/Schubeler-Consulting/knowmind/badges/card.svg)](https://glama.ai/mcp/servers/Schubeler-Consulting/knowmind)

Score Badge

Copy to your README.md:

[![knowmind MCP server](https://glama.ai/mcp/servers/Schubeler-Consulting/knowmind/badges/score.svg)](https://glama.ai/mcp/servers/Schubeler-Consulting/knowmind)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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