Skip to main content
Glama
GreptimeTeam

GreptimeDB MCP Server

Official
by GreptimeTeam

query_semantic_graph

Explore entities and relationships in a semantic graph over a time window. Use summary to discover types, then query entities or relationships by type or id.

Instructions

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 the attributes an id was assembled from and
source_tables names the telemetry tables that witnessed it. Identifiers
from alerts and other tools are not graph ids unless a query here returned
that exact string.

When masking is on, a returned field is hidden if its own name matches a
sensitive pattern, and an attribute map is also masked by the names inside
it. entities additionally hides entity_id when a masked attribute helped
build it; relationships cannot do the same, because its view does not carry
attribute names, so such a value can still appear there as src_id or
dst_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewYessummary: which entity and relationship types exist and what they connect. entities: the nodes. relationships: the edges.
limitNoMaximum rows to return.
scopeNoentities only: the namespace or environment an id is scoped to.
dst_idNorelationships only: a canonical destination id this graph returned.
src_idNorelationships only: a canonical source id this graph returned.
dst_typeNorelationships only: destination endpoint type.
end_timeYesExclusive end of the window, RFC3339.
rel_typeNorelationships only: calls, runs_on, contains, part_of, uses, invokes, depends_on, owns, or a custom declared value.
src_typeNorelationships only: source endpoint type.
entity_idNoentities only: a canonical id this graph returned.
provenanceNorelationships only: how the edge was obtained -- trace (paired spans), attribute (identities on one row), declared, or agent.
start_timeYesInclusive start of the window, RFC3339, e.g. 2026-09-05T07:00:00Z. Without an offset it is read as UTC.
entity_typeNoentities only: service, k8s.pod, host, ...

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it reveals the confidence 1.0/0.5 representation, duplicate rows for edges observed both ways, half-open windows over observed_at buckets, row-level semantics for entities (item_count counts rows, not entities), behavior when complete is false, masking effects, and the caveat that a missing edge is not evidence of non-relation. This is far beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is long but every paragraph earns its place and is organized by topic: purpose, window, per-view row semantics, ordering, interpretation caveats, provenance, and masking. The main purpose and view-selection rule are front-loaded in the first two sentences, so an agent quickly gets the gist without needing the later detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters, no annotations, and a complex output schema, the description is unusually complete: it covers view-specific behavior, edge cases (sampling, unmatched clients, identity deduplication), ordering rules, provenance, and masking. Nothing an agent needs to call this tool correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning the schema does not: it defines the window as half-open over observed_at 60-second buckets, clarifies that rel_type=calls is needed to order by error/request counts, explains what limit echoes and what complete=false means, and details provenance/identity semantics for src_id/dst_id and entity_id. That is substantial added value over the 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?

The opening sentence names a specific verb ('Query'), a specific resource ('semantic graph'), and the two core questions it answers ('which entities exist and which are related'). It further distinguishes the three views (summary, entities, relationships) at a high level, so an agent can tell it apart from sibling data-query tools without reading the schema.

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 description gives clear internal routing: use view=summary when types are unknown, and query entities or relationships directly once a type or id is in hand. It does not explicitly contrast this tool with sibling tools like execute_sql or query_range, so the when-not-to-use guidance for the tool itself is left implicit, but the context is strong.

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