Skip to main content
Glama

create_relations

Define and establish relationships between entities in a knowledge graph. Specify source, target, and relation type to actively build structured connections for enhanced reasoning and problem-solving.

Instructions

Create multiple new relations between entities in the knowledge graph. Relations should be in active voice

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
relationsYesArray of relations to create

Implementation Reference

  • The core execute function for the 'create_relations' tool. It processes an array of relations, attempts to add each to the graph using graph.addRelation, checks for existence of source/target entities or duplicate relations for failures, collects results, saves the memory store, and returns a JSON string with created/failed counts and details.
    execute: async (args) => {
      const results = {
        created: [] as Array<{from: string, to: string, relationType: string}>,
        failed: [] as Array<{from: string, to: string, relationType: string, reason: string}>
      };
    
      // Using the lower-level graph for relations for now
      // In a future update, we can add relation handling to the MemoryStore itself
      for (const relation of args.relations) {
        const success = graph.addRelation(relation);
        if (success) {
          results.created.push(relation);
        } else {
          // Determine failure reason
          let reason = "Unknown error";
          if (!graph.entities.has(relation.from)) {
            reason = `Source entity '${relation.from}' doesn't exist`;
          } else if (!graph.entities.has(relation.to)) {
            reason = `Target entity '${relation.to}' doesn't exist`;
          } else {
            reason = "Relation already exists";
          }
          
          results.failed.push({...relation, reason});
        }
      }
    
      // Save changes
      await memoryStore.save();
    
      // Return as string
      return JSON.stringify({
        created: results.created.length > 0 ? results.created : null,
        failed: results.failed.length > 0 ? results.failed : null,
        message: `Created ${results.created.length} new relations. ${results.failed.length} relations failed.`
      });
    }
  • Zod schema defining the input parameters for the create_relations tool: an array of relations.
    export const CreateRelationsSchema = z.object({
      relations: z.array(RelationSchema).describe('Array of relations to create')
    });
  • Registers the 'create_relations' tool on the FastMCP server with name, description, schema, and inline execute handler.
    server.addTool({
      name: 'create_relations',
      description: 'Create multiple new relations between entities in the knowledge graph. Relations should be in active voice',
      parameters: Schemas.CreateRelationsSchema,
      execute: async (args) => {
        const results = {
          created: [] as Array<{from: string, to: string, relationType: string}>,
          failed: [] as Array<{from: string, to: string, relationType: string, reason: string}>
        };
    
        // Using the lower-level graph for relations for now
        // In a future update, we can add relation handling to the MemoryStore itself
        for (const relation of args.relations) {
          const success = graph.addRelation(relation);
          if (success) {
            results.created.push(relation);
          } else {
            // Determine failure reason
            let reason = "Unknown error";
            if (!graph.entities.has(relation.from)) {
              reason = `Source entity '${relation.from}' doesn't exist`;
            } else if (!graph.entities.has(relation.to)) {
              reason = `Target entity '${relation.to}' doesn't exist`;
            } else {
              reason = "Relation already exists";
            }
            
            results.failed.push({...relation, reason});
          }
        }
    
        // Save changes
        await memoryStore.save();
    
        // Return as string
        return JSON.stringify({
          created: results.created.length > 0 ? results.created : null,
          failed: results.failed.length > 0 ? results.failed : null,
          message: `Created ${results.created.length} new relations. ${results.failed.length} relations failed.`
        });
      }
    });
  • Invokes registerMemoryTools(server) as part of registering all tools, which includes the create_relations tool.
    console.error('[INFO] [tools] Registering memory tools...');
    registerMemoryTools(server);
  • Zod schema for individual relation objects used in CreateRelationsSchema.
    const RelationSchema = z.object({
      from: z.string().min(1).describe('Source entity name'),
      to: z.string().min(1).describe('Target entity name'),
      relationType: z.string().min(1).describe('Type of relationship (in active voice)')
    });
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates relations, implying a write operation, but lacks critical details: it doesn't specify permissions needed, whether relations are immutable after creation, error handling for duplicate relations, or what the response contains. The active voice requirement is noted, but overall behavioral context is insufficient for a mutation tool.

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 extremely concise with two sentences that directly address the tool's function and a key constraint. It's front-loaded with the core purpose and avoids any unnecessary elaboration, making it efficient and easy to parse without wasted words.

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

Completeness2/5

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

Given the complexity of a write operation to a knowledge graph with no annotations and no output schema, the description is incomplete. It fails to explain what happens upon success (e.g., returns created relation IDs), error conditions, or side effects. For a tool that mutates graph data, this leaves significant gaps in understanding how to use it effectively.

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%, so the schema fully documents the 'relations' parameter and its nested structure. The description adds minimal value beyond this, only implying that relations are 'multiple' and 'new', which is redundant with the schema. No additional semantics about parameter constraints or usage are provided, meeting the baseline for high schema coverage.

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 the action ('Create multiple new relations') and the target resource ('between entities in the knowledge graph'), which is specific and actionable. It distinguishes from siblings like 'delete_relations' and 'update_relations' by focusing on creation, though it doesn't explicitly contrast with 'upsert_entities' which might overlap. The active voice requirement adds nuance but doesn't fully differentiate from all alternatives.

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?

The description provides no guidance on when to use this tool versus alternatives. It mentions 'relations should be in active voice', which is a constraint rather than usage context. There's no indication of prerequisites, when to choose this over 'upsert_entities' or 'update_relations', or any exclusions, leaving the agent to infer based on tool names alone.

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

Install Server

Other Tools

Related Tools

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/flight505/mcp-think-tank'

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