Skip to main content
Glama
tigergraph

tigergraph-mcp

Official
by tigergraph

tigergraph__run_query

Destructive

Run ad-hoc GSQL or openCypher queries on a TigerGraph graph without installation. Ideal for testing, prototyping, and quick data retrieval.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileNoConnection profile name. Omit to use the active default profile. Use 'list_connections' to see available profiles.
graph_nameNoName of the graph. If not provided, uses default connection.
query_textYesQuery text to interpret and run. Supports both GSQL and openCypher queries. For GSQL: use 'INTERPRET QUERY () FOR GRAPH <graph> { <gsql_statements> }'. For openCypher: use 'INTERPRET OPENCYPHER QUERY () FOR GRAPH <graph> { <cypher_statements> }'. The query type is auto-detected based on the INTERPRET keyword used. Example (GSQL): `INTERPRET QUERY () FOR GRAPH MyGraph { SELECT v FROM Person:v }`Example (Cypher): `INTERPRET OPENCYPHER QUERY () FOR GRAPH MyGraph { MATCH (n) RETURN n LIMIT 5 }`

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.3/5.0
Behavior4/5

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

Annotations carry destructiveHint=true, and the description adds genuinely useful behavioral context beyond that: query type auto-detection (GSQL vs Cypher), the mandatory 'FOR GRAPH' clause, and a LIMIT tip to cap result size. Minor gap: the 'Simple data retrieval operations' bullet mildly underplays that interpreted queries can also mutate data, but this does not contradict the destructiveHint annotation.

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?

Well-structured with purpose, Use When, Quick Start, Workflow, Tips, and Related Tools sections; core purpose is front-loaded. Slightly long, and the Syntax Notes section partially duplicates the schema's query_text examples, but the length is justified for a tool supporting two query languages with distinct syntax.

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?

Highly complete for a complex two-language query executor: it provides syntax templates, workflow guidance, performance guidance, and sibling routing. The main gap is that no output schema exists and the description never hints at what the result looks like; otherwise an agent has everything needed to call it correctly.

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 baseline is 3. The schema already documents profile, graph_name, and query_text with syntax templates and examples for both languages. The description's Quick Start payloads reinforce but do not add semantically new parameter meaning beyond the schema, so it stays at baseline.

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?

Opens with a specific verb+resource: 'Run an interpreted query on a TigerGraph graph.' It names both supported languages (GSQL and openCypher) and immediately differentiates from siblings by stating 'without needing to install them first,' which cleanly separates it from run_installed_query. The Related Tools section reinforces the distinction.

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?

Contains an explicit 'Use When' section listing concrete scenarios (ad-hoc, testing before install, prototyping), plus a 'For frequent queries, use install_query + run_installed_query for better performance' exclusion that routes the agent to alternatives. The Common Workflow provides a step-by-step decision path anchored on a sibling (show_graph_details).

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

Deploy Server

Other Tools