Skip to main content
Glama
tigergraph

tigergraph-mcp

Official
by tigergraph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

tigergraph__update_schema

Destructive

Apply incremental schema changes to add or drop vertex types, edge types, or attributes on existing graphs or globally.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileNoConnection profile name. If not provided, uses TG_PROFILE env var or 'default'.
graph_nameNoName of the graph to modify. If not provided, runs a global schema change.
add_edge_typesNoEdge type definitions to add (same format as create_graph).
drop_edge_typesNoNames of edge types to drop.
add_vertex_typesNoVertex type definitions to add (same format as create_graph).
drop_vertex_typesNoNames of vertex types to drop.
add_vertex_attributesNoMap of vertex type name to list of attributes to add. E.g. {"Person": [{"name": "score", "type": "FLOAT"}]}
drop_vertex_attributesNoMap of vertex type name to list of attribute names to drop. E.g. {"Person": ["old_attr"]}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.5/5.0
Behavior5/5

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

The destructiveHint annotation already flags mutating behavior, and the description adds meaningful detail: warnings to drop referencing edges before vertex types, note that defaults avoid nulls on existing data, and clarification that omitting graph_name switches from local to global scope, affecting blast radius.

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?

The markdown structure (Use When, examples, Tips, Related Tools) makes it scannable and the summary is front-loaded. Minor redundancy exists: local/global scope is stated in the intro, Use When bullets, and Tips, so not every sentence is strictly necessary.

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?

For a schema-mutation tool with 8 parameters and no output schema, this description covers operation types, target scope, ordering constraints, and safe pre-checks, and names related tools. It does not describe response/return behavior or explicitly state whether multiple change types can be combined, but the schema and annotations cover most remaining essentials.

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?

The input schema already documents all 8 parameters with 100% coverage, so the baseline is 3. The description adds JSON examples for local vs global add_vertex_types calls and an explicit explanation of graph_name omission semantics, which illustrates what the schema states without example.

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?

The opening sentence names the exact action ('Apply incremental schema changes') and resources ('vertex types, edge types, or individual attributes'), and specifies local vs global scope. This is specific enough to distinguish it from create_graph/drop_graph before looking at parameters.

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?

The 'Use When' section gives concrete scenarios: adding to an existing graph, creating global types, dropping types, and altering attributes. The 'Related Tools' list names alternatives, but the description does not explicitly say 'for new graph creation use create_graph', so it lacks an explicit when-not rule.

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