Repository navigation
Release v1.0.2
tigergraph-mcp 1.0.2 Release Notes
New
- HTTP/SSE transport for multi-user deployments —
--transport streamable-http|sseserves many users from one process, each session owning its own isolated TigerGraph connections. Clients supply credentials asX-TG-*headers; the server's env file supplies the connection profiles. Requiresuvicornandstarlette. - Data warehouse and lakehouse data sources — Snowflake, BigQuery, PostgreSQL, Iceberg, Kafka v2, and MirrorMaker, alongside the existing object store and Kafka types.
- Loading from a warehouse query — a loading job may read the result of a SQL query against a data source instead of a file.
- Four new tools (69 total) —
get_data_source_types,authenticate,update_query_description, andget_query_description.
Changed
- Data source configuration keys now match what TigerGraph requires. Several documented keys were wrong for Google Cloud Storage, Azure Blob, and Kafka; S3 requires both credential keys, and PostgreSQL's port and database name are optional.
- Data source credentials are masked in tool responses.
TG_DEFAULT_PROFILEnames the default connection profile, withTG_PROFILEkept as an alias.- Python 3.13 and 3.14 are supported and tested; the minimum stays 3.10.
- Both the 1.x and 2.x MCP SDKs are supported.
Bug Fixes
- Azure Blob data sources could never be created: the type TigerGraph accepts is
abs, andazure_blobis now translated to it. localis no longer offered as a data source type; TigerGraph does not accept it. Local files load withrun_loading_job_with_file.- A
typekey insideconfigno longer overrides thedata_source_typeargument. list_connectionsandshow_connectiondescribe the calling session rather than the server process, so an agent can discover the profiles it may use and sees the connection actually in effect.
Upgrading
No action required. stdio remains the default transport and behaves as before; HTTP mode is opt-in. If you create Azure Blob data sources, note the corrected key names.