List all available TigerGraph connection profiles. Profiles are configured via environment variables: the default profile uses TG_HOST, TG_USERNAME, etc., while named profiles use _TG_HOST, _TG_USERNAME, etc.

Show non-sensitive connection details for a specific profile (host, username, graph name, ports). Never reveals passwords or tokens.

Register TigerGraph credentials for the current MCP session.

Re-points one of the session's connections at a TigerGraph instance. Omit profile to replace the default profile's connection, or name a profile to replace only that one, leaving the session's other profiles untouched. Stdio mode uses env-var profiles instead and does not need this tool.

Either api_token/jwt_token OR username + password must be supplied. The credentials live only in the session's in-memory connection pool and are dropped on disconnect.

Get the complete global schema including all global vertex types, edge types, graphs, and their member types. Runs GSQL 'LS' command.

Use When: • You need to see all graphs and their schemas at once • Understanding the complete database structure • Finding all available vertex and edge types across all graphs • Database-level schema exploration

Quick Start:

{}

(No parameters needed)

Tips: • Returns output from GSQL 'LS' command • Shows all graphs in the database • For single graph details, use 'show_graph_details' instead • Useful for database administrators

Related Tools: list_graphs, show_graph_details, get_graph_schema

List all graph names in the TigerGraph database. Returns only graph names — no schema, query, or job details.

Use When: • Discovering what graphs exist in the database • First step when connecting to a new TigerGraph instance • Verifying a graph was created or dropped successfully

Quick Start:

{}

(No parameters needed)

Next Steps: • Use 'show_graph_details' to see everything under a graph (schema, queries, jobs) • Use 'get_graph_schema' to get just the schema (vertex/edge types)

Related Tools: show_graph_details, get_graph_schema, create_graph

Create a new graph in the TigerGraph database with its schema (vertex types and edge types). Each graph has its own independent schema.

Use When: • Creating a new graph from scratch • Setting up a graph with specific vertex and edge types • Initializing a new project or data model • Defining the structure before loading data

Quick Start:

{
  "graph_name": "SocialNetwork",
  "vertex_types": [
    {
      "name": "Person",
      "primary_id": "id",
      "primary_id_type": "STRING",
      "attributes": [
        {"name": "name", "type": "STRING"},
        {"name": "age", "type": "INT"}
      ]
    }
  ],
  "edge_types": [
    {
      "name": "FOLLOWS",
      "from_vertex": "Person",
      "to_vertex": "Person",
      "directed": true,
      "attributes": [
        {"name": "since", "type": "STRING"}
      ]
    }
  ]
}

Common Workflow:

1. Use 'list_graphs' to check if graph name is available

2. Design your vertex types and edge types

3. Call 'create_graph' with the schema

4. Use 'show_graph_details' to verify it was created correctly

5. Start loading data with 'add_node' and 'add_edge'

Vertex Primary Key Options: • Default: auto-generates PRIMARY_ID id STRING with primary_id_as_attribute • Explicit PRIMARY_ID: set primary_id (string) and primary_id_type on vertex type • PRIMARY KEY mode: set primary_key: true on one attribute (not GraphStudio compatible) • Composite key: set primary_id to a list of attribute names, e.g. ["title", "year"] All listed attributes must exist in the attribute list (not GraphStudio compatible) • The key is always queryable as a regular attribute

Tips: • Define all vertex types before edge types • Edge types reference vertex types by name • Set 'directed': false on edge types for undirected edges (default: directed) • Consider using 'get_workflow' for step-by-step guidance

Related Tools: list_graphs, show_graph_details, drop_graph

Drop (delete) a graph and its schema from the TigerGraph database. This permanently removes the graph, its schema, and all data.

Use When: • Removing a graph that's no longer needed • Cleaning up test graphs • Starting fresh with a new schema

Quick Start:

{
  "graph_name": "TestGraph"
}

Warning: DANGER: • This deletes EVERYTHING: schema, vertices, edges, queries, loading jobs • Operation is PERMANENT and cannot be undone • Double-check the graph_name before executing • Consider using 'clear_graph_data' if you only want to remove data

Tips: • Use 'list_graphs' first to confirm the graph name • For production graphs, always backup first • To keep schema but clear data, use 'clear_graph_data'

Related Tools: create_graph, clear_graph_data, list_graphs

Clear all data (vertices and edges) from a specific graph while keeping its schema structure intact. This is a destructive operation that removes all graph data.

Use When: • Resetting a graph to empty state • Clearing test data before loading production data • Starting data reload with same schema

Quick Start:

{
  "graph_name": "MyGraph",
  "confirm": true
}

WARNING: • Deletes ALL vertices and edges in the graph • Operation is PERMANENT and cannot be undone • Must set 'confirm': true to execute • Schema (vertex/edge types) remains intact

Tips: • Preserves schema, only clears data • To delete everything including schema, use 'drop_graph' • Always backup important data first • Can specify 'vertex_type' to clear only specific type

Related Tools: drop_graph, get_vertex_count, delete_nodes

Get the schema of a specific graph — vertex types, edge types, and their attributes — as structured JSON. Returns schema only, not queries or jobs.

Use When: • You need to know vertex/edge types and their attributes • Building or validating queries against the schema • Programmatic schema inspection or comparison

Quick Start:

{
  "graph_name": "SocialNetwork"
}

Tips: • Returns structured JSON (vertex types, edge types, attributes) • For a full listing including queries and jobs, use 'show_graph_details' • For just graph names, use 'list_graphs'

Related Tools: show_graph_details (full listing), list_graphs (names only)

Show details of a specific graph. By default shows everything (schema, queries, loading jobs, data sources). Use 'detail_type' to show only a specific category.

Use When: • You need a full picture of a graph (schema + queries + jobs) • Starting work with a graph (call this first!) • Checking which queries or loading jobs are installed • Debugging schema or job issues

Quick Start:

{ "graph_name": "SocialNetwork" }

(Shows everything under the graph)

Filter by category:

{ "graph_name": "SocialNetwork", "detail_type": "query" }

Options: 'schema', 'query', 'loading_job', 'data_source'

Tips: • No detail_type → shows all (GSQL LS output) • For structured JSON schema, use 'get_graph_schema' instead • For just graph names, use 'list_graphs' • For vector attributes, use 'list_vector_attributes' instead

Related Tools: get_graph_schema (schema JSON), list_graphs (names only), list_vector_attributes (vector attribute details)

Apply incremental schema changes: add/drop vertex types, edge types, or individual attributes. Supports both local (graph-scoped) and global schema changes.

Use When:

• Adding new vertex or edge types to an existing graph (local)

• Creating global vertex/edge types shared across graphs (global)

• Dropping vertex or edge types that are no longer needed

• Adding or removing attributes on existing vertex types

Local schema change (add a vertex type to a graph):

{
  "graph_name": "MyGraph",
  "add_vertex_types": [{"name": "Product", "attributes": [{"name": "price", "type": "FLOAT"}]}]
}

Global schema change (omit graph_name):

{
  "add_vertex_types": [{"name": "SharedVertex", "attributes": [{"name": "val", "type": "INT"}]}]
}

Tips:

• Drop edges referencing a vertex type before dropping the vertex type

• Adding attributes with defaults avoids null values on existing data

• Use 'get_graph_schema' to inspect the current schema first

• Omit 'graph_name' to apply changes at the global level

Related Tools: create_graph, get_graph_schema, show_graph_details

Validate vertex type names, edge type names, attribute names, and the graph name against GSQL reserved keywords and naming conflict rules.

Use When:

• Before calling 'create_graph' to catch naming problems early

• Checking if user-supplied names conflict with GSQL keywords

• Validating that vertex/edge type names don't collide with their attribute names

Quick Start:

{
  "graph_name": "MyGraph",
  "vertex_types": [
    {"name": "SELECT", "attributes": [{"name": "count", "type": "INT"}]}
  ]
}

(Returns warnings for 'SELECT' and 'count' as reserved keywords)

Related Tools: create_graph, get_graph_schema

Add a single node (vertex) to a TigerGraph graph. This performs an upsert operation - creates a new vertex if it doesn't exist, or updates attributes if it does.

Use When: • Creating a single new entity (user, product, document, etc.) • Updating an existing vertex's attributes • You have individual entities to add (not batch loading)

Quick Start:

{
  "vertex_type": "Person",
  "vertex_id": "user123",
  "attributes": {"name": "Alice", "age": 30}
}

Common Workflow:

1. Call 'show_graph_details' to understand vertex types and attributes

2. Use 'add_node' to create individual vertices

3. Call 'get_node' to verify the vertex was created

4. Use 'add_edge' to connect this vertex to others

Tips: • For multiple vertices: Use 'add_nodes' instead (more efficient) • Primary key is required (usually the 'id' attribute) • Attribute names must match the schema exactly (case-sensitive) • This is an upsert: existing vertices are updated, not duplicated

More Examples:

// Add a product
{
  "vertex_type": "Product",
  "vertex_id": "prod456",
  "attributes": {"name": "Laptop", "price": 999.99, "category": "Electronics"}
}

// Add a document with minimal attributes
{
  "vertex_type": "Document",
  "vertex_id": "doc789",
  "attributes": {"title": "Report Q4 2024"}
}

Related Tools: • add_nodes - Batch insert multiple vertices • get_node - Retrieve a vertex by ID • delete_node - Remove a vertex • has_node - Check if vertex exists

Add multiple nodes (vertices) to a TigerGraph graph in a single batch operation. This is significantly more efficient than calling 'add_node' multiple times.

Use When: • Loading multiple vertices of the same type • Importing data from CSV, JSON, or database • Initial data population • Bulk updates to existing vertices

Quick Start:

{
  "vertex_type": "Person",
  "vertices": [
    {"id": "user1", "name": "Alice", "age": 30},
    {"id": "user2", "name": "Bob", "age": 25}
  ]
}

Common Workflow:

1. Call 'show_graph_details' to understand the schema

2. Prepare your data with primary keys and attributes

3. Use 'add_nodes' to load vertices in batches

4. Call 'get_vertex_count' to verify loading

5. Use 'add_edges' to create relationships

Tips: • Set 'vertex_id' to match your schema's primary key name (default: 'id') • For SARGraph: vertex_id='ACCOUNT_ID' for Account vertices • All vertices must be the same type • For very large datasets (>10K vertices), consider using loading jobs • Batch size: 1000-5000 vertices per call is optimal

Warning: Common Mistakes: • Missing primary key in one or more vertices • Using wrong vertex_id name (check schema with show_graph_details) • Mixing different vertex types in one call • Attribute name typos (must match schema exactly) • Wrong data types (e.g., string instead of int)

Get a single node (vertex) from a TigerGraph graph by its type and ID.

Use When: • Retrieving a specific entity by its ID • Verifying a vertex was created successfully • Checking current attribute values • Fetching details before updating

Quick Start:

{
  "vertex_type": "Person",
  "vertex_id": "user123"
}

Related Tools: • get_nodes - Get multiple vertices • has_node - Check if vertex exists • get_node_edges - Get edges connected to vertex

Purpose: Retrieve multiple vertices (nodes) from the graph with optional filtering and sorting.

When to Use:

• List vertices of a specific type

• Search for vertices matching certain criteria

• Browse graph data with pagination

• Find vertices based on attribute values

Key Features:

• WHERE clause for filtering

• Sorting by attributes (ascending/descending)

• Limit results for pagination

• Returns complete vertex data including all attributes

Common Workflows:

1. List all vertices: get_nodes(vertex_type='Person', limit=10)

2. Filter by attribute: get_nodes(vertex_type='Person', where='age > 25')

3. Sort results: get_nodes(vertex_type='Person', sort='-created_at', limit=20)

Tips:

• Use limit to avoid retrieving too many vertices

• WHERE clause syntax follows TigerGraph conventions

• Sort with '-' prefix for descending order

• Combine where, sort, and limit for precise queries

Related Tools:

• get_node: Get a single specific vertex

• get_vertex_count: Count vertices before retrieving

• run_query: For complex multi-hop queries

Purpose: Delete a single vertex (node) from the graph by its ID.

When to Use:

• Remove a specific vertex from the graph

• Clean up obsolete data

• Delete test data

• Remove entities based on business logic

Important Notes:

• Warning: This operation is permanent and cannot be undone

• Connected edges will also be deleted (CASCADE behavior)

• Verify the vertex exists before deletion if needed

Common Workflows:

1. Safe delete: has_node() → delete_node() → verify with get_node()

2. Bulk delete: Use delete_nodes() with WHERE clause instead

Tips:

• Use has_node() first to verify existence

• Consider the impact on connected edges

• For multiple deletions, use delete_nodes() for better performance

Related Tools:

• delete_nodes: Delete multiple vertices at once

• has_node: Check if vertex exists before deletion

• get_node: Verify deletion completed

Purpose: Delete multiple vertices (nodes) from the graph in a single operation.

When to Use:

• Bulk deletion of vertices matching criteria

• Delete specific set of vertices by IDs

• Clear all vertices of a type

• Data cleanup operations

Important Notes:

• Warning: This operation is permanent and cannot be undone

• Warning: Omitting WHERE will delete ALL vertices of the specified type

• Connected edges will also be deleted (CASCADE behavior)

• More efficient than multiple delete_node() calls

Usage Modes:

1. By WHERE clause: delete_nodes(vertex_type='Person', where='age > 70')

2. By ID list: delete_nodes(vertex_type='Person', vertex_ids=['id1', 'id2'])

3. Delete all: delete_nodes(vertex_type='TempData') (no where/ids)

Safety Tips:

• ALWAYS test WHERE clause with get_nodes() first

• Use get_vertex_count() to verify expected deletion count

• Consider backing up data before bulk deletions

Related Tools:

• delete_node: Delete a single vertex

• get_nodes: Preview vertices before deletion

• get_vertex_count: Check deletion impact

Purpose: Check if a vertex (node) exists in the graph without retrieving its full data.

When to Use:

• Verify a vertex exists before operations

• Validation in data pipelines

• Conditional logic based on vertex existence

• Lightweight existence checks (faster than get_node)

Key Features:

• Returns simple boolean result (exists: true/false)

• More efficient than get_node() for existence checks

• No data transfer overhead

Common Workflows:

1. Safe operations: has_node() → if true, proceed with get_node()/delete_node()

2. Validation: Check required vertices exist before adding edges

3. Conditional creation: If not exists, create with add_node()

Tips:

• Use this instead of get_node() when you only need existence confirmation

• Combine with add_node() for upsert logic

• Faster than catching errors from get_node()

Related Tools:

• get_node: Retrieve full vertex data if it exists

• add_node: Create vertex if it doesn't exist

• delete_node: Remove vertex after confirming existence

Purpose: Retrieve all edges connected to a specific vertex (node).

When to Use:

• Explore connections from a vertex

• Find relationships of a specific type

• Analyze node connectivity patterns

• Get edge attributes and target vertices

What You Get:

• Edge type and ID

• Edge attributes

• Target vertex information

• Edge direction (outgoing from the specified vertex)

Common Workflows:

1. Explore all connections: get_node_edges(vertex_type='Person', vertex_id='123')

2. Specific relationship type: get_node_edges(..., edge_type='FRIEND_OF')

3. Degree analysis: Count returned edges to get outgoing degree

Tips:

• Returns OUTGOING edges only (edges starting from this vertex)

• Use get_node_degree() for quick connection count

• Use get_neighbors() to get target vertices without edge details

• Combine with pagination (limit) for highly connected vertices

Note: This returns edges where the specified vertex is the SOURCE. For incoming edges, use a reverse traversal query or get_neighbors().

Related Tools:

• get_node_degree: Count connections without retrieving edges

• get_neighbors: Get connected vertices

• get_edges: Query edges by type across the graph

Add a single edge (relationship) to a TigerGraph graph connecting two vertices.

Use When: • Creating a relationship between two entities • Connecting vertices in the graph • Building graph structure • Adding individual relationships

Quick Start:

{
  "source_vertex_type": "Person",
  "source_vertex_id": "user1",
  "edge_type": "FOLLOWS",
  "target_vertex_type": "Person",
  "target_vertex_id": "user2",
  "attributes": {"since": "2024-01-15"}
}

Common Workflow:

1. Ensure both source and target vertices exist (use 'add_node')

2. Call 'add_edge' to create relationship

3. Optionally add edge attributes (like timestamps)

4. Verify with 'get_neighbors' or 'get_node_edges'

Tips: • Both vertices must exist before adding edge • Edge type must match schema definition • For multiple edges, use 'add_edges' (more efficient) • Edge attributes are optional

Related Tools: add_edges, add_node, get_neighbors, delete_edge

Add multiple edges (relationships) to a TigerGraph graph in a single batch operation. More efficient than calling 'add_edge' multiple times.

Use When: • Loading multiple relationships • Building graph connections in bulk • Importing relationship data from files • Initial graph construction

Quick Start:

{
  "edge_type": "FOLLOWS",
  "edges": [
    {"from_type": "Person", "from_id": "u1", "to_type": "Person", "to_id": "u2"},
    {"from_type": "Person", "from_id": "u2", "to_type": "Person", "to_id": "u3"}
  ]
}

Common Workflow:

1. Add all vertices first with 'add_nodes'

2. Use 'add_edges' to create relationships

3. Verify with 'get_edge_count'

Tips: • All edges in one call must be same edge type • All referenced vertices must exist • Batch size: 1000-5000 edges per call is optimal • Much faster than individual 'add_edge' calls

Related Tools: add_edge, add_nodes, get_edge_count

Get a single edge (relationship) from a TigerGraph graph by specifying source, target, and edge type.

Use When: • Retrieving a specific relationship • Checking edge attributes • Verifying edge was created

Quick Start:

{
  "source_vertex_type": "Person",
  "source_vertex_id": "user1",
  "edge_type": "FOLLOWS",
  "target_vertex_type": "Person",
  "target_vertex_id": "user2"
}

Tips: • Requires full edge specification (source, target, type) • Returns edge attributes if any • Use 'get_neighbors' for simpler neighbor queries

Related Tools: get_edges, has_edge, get_neighbors

Get multiple edges (relationships) from a TigerGraph graph, optionally filtered by type.

Use When: • Retrieving multiple edges • Exploring graph relationships • Data export and analysis

Quick Start:

{
  "source_vertex_type": "Person",
  "source_vertex_id": "user1",
  "edge_type": "FOLLOWS"
}

Tips: • Can filter by edge type • Returns all edges from a source vertex • Use 'get_neighbors' for simpler use cases

Related Tools: get_edge, get_neighbors, get_edge_count

Delete a single edge (relationship) from a TigerGraph graph.

Use When: • Removing a specific relationship • Disconnecting two vertices • Graph maintenance

Quick Start:

{
  "source_vertex_type": "Person",
  "source_vertex_id": "user1",
  "edge_type": "FOLLOWS",
  "target_vertex_type": "Person",
  "target_vertex_id": "user2"
}

Warning: • Operation is permanent • Does not delete the vertices, only the edge

Related Tools: delete_edges, add_edge, has_edge

Delete multiple edges (relationships) from a TigerGraph graph.

Use When: • Removing multiple relationships • Bulk edge deletion • Graph restructuring

Quick Start:

{
  "edge_type": "FOLLOWS",
  "edges": [
    {"from_type": "Person", "from_id": "u1", "to_type": "Person", "to_id": "u2"},
    {"from_type": "Person", "from_id": "u2", "to_type": "Person", "to_id": "u3"}
  ]
}

Warning: • Operation is permanent and cannot be undone • Does not delete vertices

Related Tools: delete_edge, add_edges

Check if an edge (relationship) exists between two vertices without retrieving its data.

Use When: • Verifying relationship existence • Validation logic • More efficient than get_edge when you only need existence check

Quick Start:

{
  "source_vertex_type": "Person",
  "source_vertex_id": "user1",
  "edge_type": "FOLLOWS",
  "target_vertex_type": "Person",
  "target_vertex_id": "user2"
}

Tips: • Returns boolean (true/false) • Faster than get_edge when you don't need the data • Use before add_edge to avoid duplicates

Related Tools: get_edge, add_edge

Run an interpreted query on a TigerGraph graph. Supports both GSQL and openCypher query languages. Use this for ad-hoc queries without needing to install them first.

Use When: • Running one-time or ad-hoc queries • Testing queries before installation • Simple data retrieval operations • Prototyping and exploration

Quick Start (GSQL):

{
  "query_text": "INTERPRET QUERY () FOR GRAPH MyGraph { SELECT v FROM Person:v LIMIT 5; PRINT v; }"
}

Quick Start (Cypher):

{
  "query_text": "INTERPRET OPENCYPHER QUERY () FOR GRAPH MyGraph { MATCH (n:Person) RETURN n LIMIT 5 }"
}

Common Workflow:

1. Call 'show_graph_details' to understand the schema

2. Write your query using vertex/edge types from schema

3. Run with 'run_query' to test

4. For repeated use, install with 'install_query'

Tips: • Query type auto-detected (GSQL vs Cypher) • For frequent queries, use 'install_query' + 'run_installed_query' for better performance • Always include 'FOR GRAPH' clause • Use LIMIT to avoid retrieving too much data

Warning: Syntax Notes: • GSQL: INTERPRET QUERY () FOR GRAPH <name> { <statements> } • Cypher: INTERPRET OPENCYPHER QUERY () FOR GRAPH <name> { <cypher> }

Related Tools: run_installed_query, install_query, get_neighbors

Run an installed GSQL query on a TigerGraph graph with parameters. Faster than interpreted queries for repeated execution.

Use When: • Running pre-installed, compiled queries • Queries that are executed frequently • Performance-critical operations • Parameterized queries with different inputs

Quick Start:

{
  "query_name": "getPersonFriends",
  "params": {"personId": "user123", "maxHops": 2}
}

Common Workflow:

1. Install query once with 'install_query'

2. Run multiple times with 'run_installed_query' and different params

3. Much faster than 'run_query' for repeated use

Tips: • Queries must be installed first with 'install_query' • Use 'is_query_installed' to check if query exists • Provide params as dictionary matching query signature • Faster than interpreted queries

Related Tools: install_query, is_query_installed, show_query

Install a GSQL query on a TigerGraph graph, compiling it for faster repeated execution.

Use When: • You have a query you'll run multiple times • You want better query performance • Creating reusable query logic • Building query libraries

Quick Start:

{
  "query_text": "CREATE QUERY getPersonFriends(VERTEX<Person> p) FOR GRAPH MyGraph { ... }"
}

Common Workflow:

1. Write and test query with 'run_query' first

2. Once working, install with 'install_query'

3. Run with 'run_installed_query' (faster)

Tips: • Query text should start with 'CREATE QUERY' • Installation compiles the query for better performance • Can define parameters in query signature • Use 'show_query' to view installed query text

Related Tools: run_installed_query, drop_query, show_query

Drop (delete) an installed query from TigerGraph.

Use When: • Removing queries no longer needed • Cleaning up test queries • Before re-installing a modified query

Quick Start:

{
  "query_name": "oldQuery"
}

Warning: • Permanently deletes the installed query • Cannot be undone • Any code calling this query will fail

Tips: • Use 'show_query' first to review before dropping • Cannot drop queries being used by other queries

Related Tools: install_query, show_query, is_query_installed

Show the GSQL text of an installed query.

Use When: • Reviewing what an installed query does • Debugging query behavior • Understanding existing queries • Documenting installed queries

Quick Start:

{
  "query_name": "getPersonFriends"
}

Tips: • Returns the full GSQL query text • Query must be installed first • Use 'is_query_installed' to check existence

Related Tools: install_query, get_query_metadata, is_query_installed

Get metadata about an installed query including parameters, return type, and other details.

Use When: • Understanding query parameters and signature • Discovering what queries are available • Building query documentation • Programmatic query discovery

Quick Start:

{
  "query_name": "getPersonFriends"
}

Tips: • Shows query parameters, types, and metadata • Helps understand how to call the query • Use 'show_query' to see the actual query text

Related Tools: show_query, is_query_installed, run_installed_query

Set a human-readable description for an installed query and, optionally, descriptions for each of its parameters. Requires TigerGraph 4.0+.

Use When: • Documenting what an installed query does and what its parameters mean • Making queries self-describing for agents and other consumers

Quick Start:

{
  "query_name": "getPersonFriends",
  "query_description": "Return the friends of a given person.",
  "parameter_descriptions": {"personId": "ID of the person to look up"}
}

Tips: • Query must be installed first • Omit 'parameter_descriptions' to set only the query-level description • Read it back with 'get_query_description'

Related Tools: get_query_description, get_query_metadata, show_query

Get the description and parameter descriptions of one or more installed queries. Requires TigerGraph 4.0+.

Use When: • Discovering what a query does and what each parameter means • Building query documentation • Understanding a query's parameters together with their descriptions

Quick Start:

{
  "query_name": "getPersonFriends"
}

Tips: • Pass 'all' (the default) to read descriptions for every query • Pair with 'get_query_metadata' to combine parameter types and descriptions • Set descriptions with 'update_query_description'

Related Tools: update_query_description, get_query_metadata, show_query

Check if a query is installed in TigerGraph without running it.

Use When: • Verifying query installation • Before trying to run an installed query • Conditional query logic

Quick Start:

{
  "query_name": "getPersonFriends"
}

Tips: • Returns true/false • Faster than trying to run and catching errors • Use before 'run_installed_query'

Related Tools: install_query, run_installed_query, show_query

Get neighbor vertices connected to a source vertex via edges. Useful for 1-hop graph traversal to find connected entities.

Use When: • Finding vertices directly connected to a vertex • 1-hop traversal (immediate neighbors) • Discovering relationships • Building recommendation lists

Quick Start:

{
  "vertex_type": "Person",
  "vertex_id": "user123",
  "edge_type": "FOLLOWS"
}

Common Workflow:

1. Have a source vertex ID

2. Call 'get_neighbors' with vertex info

3. Optionally filter by edge type

4. Receive list of connected vertices

Tips: • Simpler than writing a query for 1-hop traversal • Can filter by edge type (e.g., only 'FOLLOWS' edges) • Can specify target vertex type • For multi-hop traversal, use 'run_query' instead

Examples: • Find friends: edge_type='FRIENDS' • Find purchases: edge_type='PURCHASED', target_vertex_type='Product' • Find all connections: omit edge_type

Related Tools: get_node_edges, run_query, add_edge

Create a loading job from structured configuration. The job defines how to load data from files into vertices and edges. Each file config specifies: file alias, separator, header, EOL, and mappings. Node mappings define which columns map to vertex attributes. Edge mappings define source/target columns and edge attributes. Optionally run the job immediately and drop it after execution.

Execute a loading job with a data file. The file is uploaded to TigerGraph and loaded according to the specified loading job definition.

Execute a loading job with inline data string. The data is posted to TigerGraph and loaded according to the specified loading job definition.

Get a list of all loading jobs defined for the current graph.

Get the status of a specific loading job by its job ID.

Drop (delete) a loading job from the graph.

Get the count of vertices in a TigerGraph graph.

Get the count of edges in a TigerGraph graph.

Get the degree (number of connected edges) of a node in a TigerGraph graph.

Execute a GSQL command on TigerGraph. Use this for administrative tasks (e.g., creating users, granting roles) or schema modifications (e.g., CREATE VERTEX). Do NOT use this for running data queries (SELECT statements) - use run_query instead. Example: CREATE USER alice WITH PASSWORD 'password' or LS.

Generate a GSQL query from a natural language description using an LLM. Use this tool when you need to create a GSQL query but are unsure of the exact syntax. The generated query can then be executed using the gsql tool. For best results, provide the graph_name so the schema can be used to generate accurate queries. Configure the LLM via env vars: LLM_MODEL (e.g., 'gpt-4o' or 'openai:gpt-4o') and optionally LLM_PROVIDER.

Generate an openCypher query from a natural language description using an LLM. Use this tool when you prefer Cypher syntax over GSQL. The generated query will be wrapped in TigerGraph's INTERPRET OPENCYPHER QUERY format. graph_name is required as the query needs to specify the target graph. Configure the LLM via env vars: LLM_MODEL (e.g., 'gpt-4o' or 'openai:gpt-4o') and optionally LLM_PROVIDER.

Add a vector attribute to an existing vertex type. Creates a schema change job to ALTER VERTEX with ADD VECTOR ATTRIBUTE.

Drop a vector attribute from a vertex type. Creates a schema change job to ALTER VERTEX with DROP VECTOR ATTRIBUTE.

Get vector attribute information (name, dimension, metric) for vertex types in a graph. Parses the output of the GSQL 'LS' command. Optionally filter by vertex type.

Related Tools: add_vector_attribute, drop_vector_attribute, get_vector_index_status

Check the rebuild status of vector indexes. Returns 'Ready_for_query' when complete or 'Rebuild_processing' if still building.

Upsert multiple vertices with vector data using the REST Upsert API. Vectors must be provided inline as lists of floats (i.e., already in memory). To bulk-load vectors from a local file, use 'load_vectors_from_csv' or 'load_vectors_from_json' instead.

Bulk-load vectors from a CSV/delimited file into a vertex type's vector attribute. Creates a GSQL loading job, runs it with the file, then drops the job.

File format: Each row has a vertex ID and a vector. Fields are separated by field_separator (default |). Vector elements are separated by element_separator (default ,).

Example file (field_separator='|', element_separator=','):

vertex1|0.1,0.2,0.3
vertex2|0.4,0.5,0.6

Prerequisites:

1. Vertex type must already exist

2. Vector attribute must already be added (use 'add_vector_attribute')

3. File must exist on the local machine (it is uploaded to TigerGraph via REST)

Related Tools: add_vector_attribute, load_vectors_from_json (JSON Lines alternative), upsert_vectors (REST API for in-memory data), get_vector_index_status (check indexing after load)

Bulk-load vectors from a JSON Lines (.jsonl) file into a vertex type's vector attribute. Creates a GSQL loading job with JSON_FILE="true", runs it with the file, then drops the job.

File format: Each line is a JSON object with an ID field and a vector field. The vector is stored as a comma-separated string (not a JSON array).

Example file (id_key='id', vector_key='embedding'):

{"id": "vertex1", "embedding": "0.1,0.2,0.3"}
{"id": "vertex2", "embedding": "0.4,0.5,0.6"}

Prerequisites:

1. Vertex type must already exist

2. Vector attribute must already be added (use 'add_vector_attribute')

3. File must exist on the local machine (it is uploaded to TigerGraph via REST)

Related Tools: add_vector_attribute, load_vectors_from_csv (CSV alternative), upsert_vectors (REST API for in-memory data), get_vector_index_status (check indexing after load)

Perform vector similarity search using TigerGraph's vectorSearch() function. Returns top-K most similar vertices with distance scores.

IMPORTANT: The query_vector dimensions MUST match the dimension defined in the vector attribute (e.g., if the attribute was created with DIMENSION=1536, the query vector must have exactly 1536 elements). A dimension mismatch will cause the search to fail or return incorrect results.

Use list_vector_attributes to check the expected dimension before searching.

Related Tools: list_vector_attributes (check dimension), fetch_vector (retrieve vector values), get_vector_index_status (check index readiness)

Fetch vertices with their vector data using GSQL PRINT WITH VECTOR. Note: Vector attributes cannot be fetched via REST API.

Create a new data source for loading data from object storage (S3, GCS, Azure Blob), a data warehouse (Snowflake, BigQuery, PostgreSQL), an Iceberg catalog, or Kafka. Call 'get_data_source_types' first if unsure which keys a type needs; if the server rejects the request, the response includes the keys that type requires.

Update an existing data source configuration.

Get information about a specific data source.

Drop (delete) a data source.

Get information about all data sources.

Drop all data sources. WARNING: This is a destructive operation.

List the data source types supported by 'create_data_source', with the required and optional configuration keys and an example config for each. Answers locally without contacting TigerGraph.

Preview sample data from a file in a data source.

Discover which TigerGraph tools are relevant for your task.

Use this tool when:

• You're unsure which tool to use for your goal

• You want to explore available capabilities

• You need suggestions for accomplishing a task

Returns:

• List of recommended tools with descriptions

• Use cases and complexity ratings

• Prerequisites and related tools

• Example parameters

Example: task_description: 'I want to add multiple users to the graph'

Get a step-by-step workflow template for common TigerGraph tasks.

Use this tool when:

• You need to complete a complex multi-step task

• You want to follow best practices

• You're new to TigerGraph and need guidance

Returns:

• Ordered list of tools to use

• Example parameters for each step

• Explanations of what each step accomplishes

Available workflows: create_graph, load_data, query_data, vector_search, graph_analysis, setup_connection

Get detailed information about a specific TigerGraph tool.

Use this tool when:

• You want to understand a tool's capabilities

• You need examples of how to use a tool

• You want to know prerequisites or related tools

Returns:

• Detailed tool description

• Use cases and examples

• Prerequisites and related tools

• Common next steps