io.github.GreptimeTeam/greptimedb-mcp-server

Create or update a Perses dashboard definition in GreptimeDB.

Create a new pipeline in GreptimeDB.

Delete a Perses dashboard definition from GreptimeDB.

Delete a specific version of a pipeline from GreptimeDB.

Get a table profile: schema, semantic metadata, sample rows, and guidance. Use it when deciding how to query an unfamiliar table. When the right table is not known yet, search_table_semantics first; describing candidates one by one is slower than querying the data. The semantic profile says what the table means, not what its data says. signal_type is metric, log, trace, or event; source and source_version name the ingestion protocol; pipeline names the schema that shaped the rows; semantic_options carries signal-specific facts such as metric type and unit. metadata_quality describes how the metric type was obtained -- `declared` by the protocol or `inferred` from the name -- and says nothing about telemetry quality. entity_declarations lists the entities the table contributes to the semantic graph. A null or missing semantic field means unknown, not the opposite fact.

Test a pipeline with sample data without writing to the database. You can test a pipeline in two ways: - Provide 'pipeline' with inline YAML configuration - Provide 'pipeline_name' to test a previously saved pipeline Args: pipeline: Pipeline YAML configuration (inline) pipeline_name: Name of saved pipeline (mutually exclusive with pipeline) data: Test data in JSON/NDJSON format data_type: Optional content type (e.g., 'application/x-ndjson')

Execute SQL query against GreptimeDB. Please use MySQL dialect. Read-only by default. When the server runs with write mode enabled (--allow-write / GREPTIMEDB_ALLOW_WRITE), destructive SQL (DDL/DML) is also permitted.

Execute TQL query for time-series analysis. TQL is PromQL-compatible - use standard PromQL syntax.

Analyze SQL or TQL query execution plan.

Check GreptimeDB connection status and server version.

List all Perses dashboard definitions stored in GreptimeDB.

List all pipelines or get details of a specific pipeline.

Execute time-window aggregation query using GreptimeDB's RANGE query syntax.

Query the semantic graph: which entities exist and which are related. Use view=summary when the entity and relationship types in this graph are not known yet; it reports them with the endpoint type pairs each relationship connects. With a type or an id already in hand, query entities or relationships directly. The window is required and half-open, [start_time, end_time), over observed_at -- the 60-second bucket an observation was recorded in. Rows are aggregated across the buckets in the window, and the result echoes the window and the limit it used. relationships returns one row per edge per confidence. The database reports confidence 1.0 for a bucket whose client and server spans paired and 0.5 for one where only the client was seen, and it switches request_count, error_count and the durations to whichever population that bucket describes: paired requests timed by the server span, or unmatched clients timed by their own. An edge observed both ways therefore comes back as two rows. unmatched_count reports client spans with no paired server span. Durations are in seconds. entities returns one row per distinct set of attributes, so an entity whose descriptive attributes changed inside the window appears more than once; item_count counts rows, not entities. first_seen and last_seen bound where the row was observed inside this window, not when the entity first existed. Ordering is by type and endpoint. Only `calls` edges carry request, error and duration counts, so pass rel_type=calls to order by error and request count instead. When complete is false, more rows matched than the limit and later types may be absent entirely rather than merely cut short. A missing edge is not evidence that two entities are unrelated: it can also mean the call was not instrumented, was sampled out, or fell outside this window. Entities are not deduplicated across identity schemes, so one process can appear under two ids if two sources named it differently. entity_id_attrs names th…

Find tables by observability concept when the right table name is unknown. Searches table names, semantic options, and entity declarations, and ranks tables by how many query terms they matched. Use it before describe_table when the schema is wide or table names do not say what they hold. It searches schema metadata only, never telemetry row values, so it can say which table holds Redis memory usage but not which row belongs to `Redis02`. It ranks on the values in that metadata, not on the schema's own key names, so search for `gauge` or `bytes` rather than `metric type`. Once it returns candidates, query their data or describe one of them; do not describe every candidate in turn. It covers only the database this server is connected to, unlike describe_table, which accepts a schema-qualified name. Only tables carrying a `greptime.semantic.*` option, or one a built-in convention derives a declaration for, are visible here. A table absent from the results may still exist and hold the data, so fall back to SHOW TABLES rather than concluding it is not there.