Skip to content

Release v1.0.2

Choose a tag to compare

@chengbiao-jin chengbiao-jin released this 27 Aug 20:24
· 6 commits to main since this release
3b3ae7a

tigergraph-mcp 1.0.2 Release Notes

New

  • HTTP/SSE transport for multi-user deployments — --transport streamable-http|sse serves many users from one process, each session owning its own isolated TigerGraph connections. Clients supply credentials as X-TG-* headers; the server's env file supplies the connection profiles. Requires uvicorn and starlette.
  • 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, and get_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_PROFILE names the default connection profile, with TG_PROFILE kept 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, and azure_blob is now translated to it.
  • local is no longer offered as a data source type; TigerGraph does not accept it. Local files load with run_loading_job_with_file.
  • A type key inside config no longer overrides the data_source_type argument.
  • list_connections and show_connection describe 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.