Skip to main content
Glama
Knowledge Graph Memory Server

Knowledge Graph Memory Server

Create Entities

create_entities

Create multiple new entities in a knowledge graph to store structured memories. Existing or duplicate names are skipped and reported, so use add_observations to update them.

Instructions

Create multiple new entities in the knowledge graph. An entity whose name already exists, or repeats an earlier entity in the same call, is skipped and its observations are not added; the result lists the skipped names in skipped. Use add_observations to add observations to an existing entity.

Input Schema

NameRequiredDescriptionDefault
entitiesYes

Output Schema

NameRequiredDescriptionDefault
skippedNo
entitiesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changed
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "entities": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "entityType": {
      +            "description": "The type of the entity",
      +            "type": "string"
      +          },
      +          "name": {
      +            "description": "The name of the entity",
      +            "type": "string"
      +          },
      +          "observations": {
      +            "description": "An array of observation contents associated with the entity",
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        },
      +        "required": [
      +          "name",
      +          "entityType",
      +          "observations"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "skipped": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "entities"
      +  ],
      +  "type": "object"
      +}
  3. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only cover the generic write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely non-obvious behavior: duplicate names within the call or against the graph are skipped rather than erroring, their observations are dropped, and skipped names surface in a `skipped` result field. It does not mention failure modes or auth, keeping it short of a 5.

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, zero padding, front-loaded with the action before the conflict semantics and the sibling pointer. Every clause adds information an agent needs.

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?

An output schema exists, so return values need not be explained, and the description still usefully flags the `skipped` field. Combined with annotations covering the write profile, the definition is close to complete; only the entity object structure is left to the schema.

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 reported at 0% (the top-level `entities` array is undocumented), so the description has to carry some of the load. It conveys that multiple entities with observations are passed and hints at the duplicate-name semantics, but never describes the entity object's name/entityType/observations shape. Partial compensation only.

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 ('Create multiple new entities in the knowledge graph') and explicitly distinguishes itself from add_observations, the sibling used for existing entities. An agent can route between create_entities and add_observations 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 Guidelines4/5

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

Clearly states the alternative for the adjacent case: 'Use add_observations to add observations to an existing entity.' It does not spell out a when-not-to-use clause or contrast with create_relations, but the primary routing decision is covered.

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