knowmind

knowmind_upload_document

Destructive

Ingest long-form text as one document into the tenant corpus, chunking it and creating embeddings and graph nodes; title-based versioning supersedes prior versions and detects duplicates.

Instructions

Ingest a longer text as one document into the tenant corpus: chunk splitting, embeddings, vector chunks and graph nodes. Upsert-by-title (server default): if a valid document with the same title exists in the same domain, the new version supersedes it; the old version stays retrievable via knowmind_recall_at_time, and the superseded ids come back in replaced_document_ids. If the same text already exists in another valid document of the same domain, no new document is created and the response carries deduplicated. Use for long-form or multi-fact content (a report, a page, a doc); for a single short fact use knowmind_store_memory. Returns the document id and the number of chunks written. AFTER INGESTING: extract the facts the text states about people, organisations, projects, products, technologies and hosts, and create the corresponding edges via knowmind_link. Requires write scope.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Document title. Unless replace is false, it identifies the document: a valid document with the same title in the same domain is superseded and stays retrievable via knowmind_recall_at_time.
`source`	No	Origin, a URL or file path. Free text appended to the content for provenance; it does not decide which document is superseded.
`content`	Yes	Full document text (Markdown or plain); chunked and embedded server-side.
`replace`	No	Default on knowmind.de: true, supersede the valid document with the same title in the same domain. false: store as a new document next to it.
`relations`	No	Edges from this document to the things it talks about - set them HERE, in the same call. Name the counterpart in plain words; the server finds or creates its node and draws the edge. Allowed predicate values: ABOUT (Contract\|Document\|FileResource → Topic), ASSIGNED_TO (ActionRecord\|Task → Agent\|Organization\|Person\|SoftwareAgent), CLIENT_OF (Agent\|Organization\|Person\|SoftwareAgent → Organization), CONTACT_PERSON_FOR (Person → Organization), COVERED_BY (Topic → Contract\|Document\|FileResource), DELIVERED_AS (Application → Product), DELIVERED_BY (Product → Application), DEPENDS_ON (Application → Application), DEPLOYED_TO (Application → Container), DEVELOPED_BY (Application → Agent\|Organization\|Person\|SoftwareAgent), DEVELOPS (Agent\|Organization\|Person\|SoftwareAgent → Application), ENABLES (Application → Application), FOR_CLIENT (Project → Agent\|Organization\|Person\|SoftwareAgent), HAS_ASSIGNED_TASK (Agent\|Organization\|Person\|SoftwareAgent → ActionRecord\|Task), HAS_CHILD (Person → Person), HAS_CLIENT (Organization → Agent\|Organization\|Person\|SoftwareAgent), HAS_CONTACT_PERSON (Organization → Person), HAS_EMPLOYEE (Organization → Person), HAS_OPERATED_APPLICATION (Agent\|Organization\|Person\|SoftwareAgent → Application), HAS_PARENT (Person → Person), HAS_PREDECESSOR (ActionRecord\|Project\|Task → ActionRecord\|Project\|Task), HAS_PROJECT (Agent\|Organization\|Person\|SoftwareAgent → Project), HAS_ROLE (Person → Role), HAS_SIBLING (Person → Person), HAS_SKILL (Agent\|Organization\|Person\|SoftwareAgent → Skill), HAS_SUCCESSOR (ActionRecord\|Project\|Task → ActionRecord\|Project\|Task), HOSTED_ON (Container → Host), HOSTS (Host → Container), HOSTS_APPLICATION (Container → Application), INFRASTRUCTURE_PROVIDED_BY (Host → Organization), INTEGRATES_WITH (Application → Application), IS_LED_BY (Organization → Person), KNOWS (Person → Person), LEADS (Person → Organization), OPERATED_FOR (Application → Agent\|Organization\|Person\|SoftwareAgent), PAID_BY (Agent\|Organization\|Person\|SoftwareAgent → Agent\|Organization\|Person\|SoftwareAgent), PARTNER_OF (Organization → Organization), PAYS (Agent\|Organization\|Person\|SoftwareAgent → Agent\|Organization\|Person\|SoftwareAgent), PRODUCED_BY (Contract\|Document\|FileResource → Project), PRODUCES (Project → Contract\|Document\|FileResource), PROVIDES_INFRASTRUCTURE (Organization → Host), ROLE_OF (Role → Person), SERVED_UNDER (Application → Domain), SERVES (Domain → Application), SKILL_OF (Skill → Agent\|Organization\|Person\|SoftwareAgent), SPOUSE_OF (Person → Person), SUPPLIED_BY (Agent\|Organization\|Person\|SoftwareAgent → Organization), SUPPLIES (Organization → Agent\|Organization\|Person\|SoftwareAgent), SUPPLIES_TECHNOLOGY (Organization → Technology), SUPPORTED_BY (Contract\|Document\|FileResource → Contract\|Document\|FileResource), SUPPORTS (Contract\|Document\|FileResource → Contract\|Document\|FileResource), TECHNOLOGY_SUPPLIED_BY (Technology → Organization), TECHNOLOGY_USED_BY (Technology → Application), USES_TECHNOLOGY (Application → Technology), WORKED_ON_BY (Project → Agent\|Organization\|Person\|SoftwareAgent), WORKS_FOR (Person → Organization), WORKS_ON (Agent\|Organization\|Person\|SoftwareAgent → Project)

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.5Oct 17, 2026

addedInput schema / properties / replace

Added value: +{
+  "description": "Default on knowmind.de: true, supersede the valid document with the same title in the same domain. false: store as a new document next to it.",
+  "type": "boolean"
+}

changedInput schema / properties / source / description

Previous value: -"Origin - URL or file path. Free text, stored for provenance."New value: +"Origin, a URL or file path. Free text appended to the content for provenance; it does not decide which document is superseded."

changedInput schema / properties / title / description

Previous value: -"Document title. Acts as the upsert key - an existing document with the same title is replaced."New value: +"Document title. Unless replace is false, it identifies the document: a valid document with the same title in the same domain is superseded and stays retrievable via knowmind_recall_at_time."

Changed4 schema fields changedv0.3.7Sep 9, 2026

changedInput schema / properties / content / description

Previous value: -"Volltext des Dokuments"New value: +"Full document text (Markdown or plain); chunked and embedded server-side."

addedInput schema / properties / relations

Added value: +{
+  "description": "Edges from this document to the things it talks about - set them HERE, in the same call. Name the counterpart in plain words; the server finds or creates its node and draws the edge. Allowed predicate values: ABOUT (Contract|Document|FileResource → Topic), ASSIGNED_TO (ActionRecord|Task → Agent|Organization|Person|SoftwareAgent), CLIENT_OF (Agent|Organization|Person|SoftwareAgent → Organization), CONTACT_PERSON_FOR (Person → Organization), COVERED_BY (Topic → Contract|Document|FileResource), DELIVERED_AS (Application → Product), DELIVERED_BY (Product → Application), DEPENDS_ON (Application → Application), DEPLOYED_TO (Application → Container), DEVELOPED_BY (Application → Agent|Organization|Person|SoftwareAgent), DEVELOPS (Agent|Organization|Person|SoftwareAgent → Application), ENABLES (Application → Application), FOR_CLIENT (Project → Agent|Organization|Person|SoftwareAgent), HAS_ASSIGNED_TASK (Agent|Organization|Person|SoftwareAgent → ActionRecord|Task), HAS_CHILD (Person → Person), HAS_CLIENT (Organization → Agent|Organization|Person|SoftwareAgent), HAS_CONTACT_PERSON (Organization → Person), HAS_EMPLOYEE (Organization → Person), HAS_OPERATED_APPLICATION (Agent|Organization|Person|SoftwareAgent → Application), HAS_PARENT (Person → Person), HAS_PREDECESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HAS_PROJECT (Agent|Organization|Person|SoftwareAgent → Project), HAS_ROLE (Person → Role), HAS_SIBLING (Person → Person), HAS_SKILL (Agent|Organization|Person|SoftwareAgent → Skill), HAS_SUCCESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HOSTED_ON (Container → Host), HOSTS (Host → Container), HOSTS_APPLICATION (Container → Application), INFRASTRUCTURE_PROVIDED_BY (Host → Organization), INTEGRATES_WITH (Application → Application), IS_LED_BY (Organization → Person), KNOWS (Person → Person), LEADS (Person → Organization), OPERATED_FOR (Application → Agent|Organization|Person|SoftwareAgent), PAID_BY (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PARTNER_OF (Organization → Organization), PAYS (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PRODUCED_BY (Contract|Document|FileResource → Project), PRODUCES (Project → Contract|Document|FileResource), PROVIDES_INFRASTRUCTURE (Organization → Host), ROLE_OF (Role → Person), SERVED_UNDER (Application → Domain), SERVES (Domain → Application), SKILL_OF (Skill → Agent|Organization|Person|SoftwareAgent), SPOUSE_OF (Person → Person), SUPPLIED_BY (Agent|Organization|Person|SoftwareAgent → Organization), SUPPLIES (Organization → Agent|Organization|Person|SoftwareAgent), SUPPLIES_TECHNOLOGY (Organization → Technology), SUPPORTED_BY (Contract|Document|FileResource → Contract|Document|FileResource), SUPPORTS (Contract|Document|FileResource → Contract|Document|FileResource), TECHNOLOGY_SUPPLIED_BY (Technology → Organization), TECHNOLOGY_USED_BY (Technology → Application), USES_TECHNOLOGY (Application → Technology), WORKED_ON_BY (Project → Agent|Organization|Person|SoftwareAgent), WORKS_FOR (Person → Organization), WORKS_ON (Agent|Organization|Person|SoftwareAgent → Project)",
+  "items": {
+    "properties": {
+      "confidence": {
+        "description": "Edge confidence in [0..1].",
+        "type": "number"
+      },
+      "object": {
+        "description": "Proper name of the counterpart.",
+        "type": "string"
+      },
+      "object_class": {
+        "description": "Class of the counterpart (Person, Organization, Application, Host, Technology, ...).",
+        "type": "string"
+      },
+      "object_description": {
+        "description": "One sentence about the counterpart, used when its node has to be created. Optional.",
+        "type": "string"
+      },
+      "predicate": {
+        "description": "Edge type in UPPER_SNAKE_CASE from the allowed list.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "predicate",
+      "object"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / source / description

Previous value: -"Quelle, z.B. URL oder Dateipfad"New value: +"Origin - URL or file path. Free text, stored for provenance."

changedInput schema / properties / title / description

Previous value: -"Dokument-Titel"New value: +"Document title. Acts as the upsert key - an existing document with the same title is replaced."

First observedv0.3.1Jul 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds materially: what actually happens to the superseded version (it stays retrievable via knowmind_recall_at_time), the content-based dedup behavior (no new document, response carries 'deduplicated'), and the write-scope prerequisite. This clarifies the practical meaning of the destructive flag rather than merely restating it.

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?

Front-loaded with purpose and scoping first, then upsert/dedup semantics, then when-to-use, then the required scope. Dense but every sentence carries information; the only cost is that it is long and packs several distinct concerns (title upsert, dedup, return fields, post-ingest linking) into one block.

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?

There is no output schema, and the description compensates by naming the return values it can (document id, number of chunks written, replaced_document_ids, 'deduplicated'). With annotations covering safety, auth scope stated, and the alternative tool named, nothing essential for correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the upsert-by-title resolution rule, the same-domain constraint, and content-level dedup that no parameter documents. Minor tension: the description tells the agent to set edges via knowmind_link 'AFTER INGESTING', while the relations parameter description says to set them 'HERE, in the same call', which muddies rather than clarifies that parameter.

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?

States a specific verb and resource with scope: 'Ingest a longer text as one document into the tenant corpus', then enumerates the pipeline steps (chunk splitting, embeddings, vector chunks, graph nodes). It explicitly distinguishes itself from the sibling knowmind_store_memory ('for a single short fact use knowmind_store_memory'), so an agent can route correctly without opening either schema.

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?

Gives an explicit when-to-use ('long-form or multi-fact content (a report, a page, a doc)') paired with when-not and the named alternative ('for a single short fact use knowmind_store_memory'). It also prescribes the follow-up workflow (extract facts, create edges via knowmind_link) and states the required write scope.

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

knowmind_upload_document

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools