GraphOS MCP Server

GetSubgraphMetrics

Read-onlyIdempotent

Top subgraphs/connectors by traffic/health for a graph over a time window, as compact CSV (header row + one row per subgraph per day). Columns: start timestamp, end exclusive timestamp, fetch service name, fetch count, fetch latency p50 ms, fetch latency p99 ms, fetch with errors count. Ranked by orderBy descending: default FETCH_COUNT (busiest); use FETCH_WITH_ERRORS_COUNT for most error-prone, FETCH_LATENCY_P99_MS for slowest. Rows are per-DAY buckets, so for a multi-day window sum a column per subgraph to get the window total. variantName optionally scopes to one or more variants (omit for all). subgraphName optionally scopes to one or more subgraphs by exact name (omit for all); pattern/substring matching is not supported. Note: to must be at least 1 day in the past (DAY resolution).

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	The ending timestamp for the report. Must be in the format: 2025-01-01T08:00:00Z (ISO 8601).
`from`	Yes	The starting timestamp for the report. Must be in the format: 2025-01-01T00:00:00Z (ISO 8601).
`limit`	No	Maximum number of records to return (default: 100, max 10000).
`graphId`	Yes
`orderBy`	No
`variantName`	No
`subgraphName`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`errors`	No
`extensions`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: the CSV output format, per-day bucketing requiring summation for multi-day totals, exact-name matching for subgraphName, and the constraint that `to` must be at least 1 day in the past. No contradictions with annotations.

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 description is dense but every sentence adds distinct information: purpose, columns, ranking, per-day aggregation, scoping, and time constraint. It is well-structured and front-loaded, with no redundant phrasing.

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 the tool's complexity (7 parameters, output schema, sibling tools), the description covers output format, aggregation behavior, ordering/filtering options, and critical time-window constraints. It is sufficiently complete for an agent to select and invoke the tool correctly, especially with an output schema available.

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 schema covers from/to/limit with descriptions and orderBy has a detailed enum definition, but graphId, variantName, and subgraphName lack property-level descriptions. The description compensates by explaining optional scoping, exact-name matching, and ranking semantics for orderBy. It adds meaning beyond the bare schema for the most ambiguous parameters.

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 description clearly states the tool retrieves top subgraphs/connectors by traffic/health over a time window as compact CSV, and details the columns and ranking. This specific verb+resource scope distinguishes it from sibling metrics tools like GetOperationMetrics and GetTopOperations.

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 provides clear context on how to use the tool: it explains the default ordering (FETCH_COUNT for busiest), how to select error-prone (FETCH_WITH_ERRORS_COUNT) or slowest (FETCH_LATENCY_P99_MS), and optional variant/subgraph scoping. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit exclusions.

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

All GraphOS MCP Server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a clearly distinct resource and action: docs (search/read), launches (history/get/latest), metrics (operations/subgraphs/top ops), config checks (PQL/lint/variant), and identity resolution. There is no meaningful overlap — GetLaunchHistory, GetLaunch, and GetLatestLaunch are clearly differentiated by scope. The tool set is exceptionally well delineated.

Naming Consistency3/5

The naming follows a mostly consistent pattern, but there is a notable inconsistency: seven tools use the Get* prefix (GetLaunch, GetVariantDetails, GetLintResults, etc.) while two use an inconsistent ApolloDocs* prefix (ApolloDocsSearch, ApolloDocsRead). The Get* tools are uniform, and the camelCase compound names (GetLatestLaunch, GetOperationMetrics) are readable, but the two ApolloDocs tools break the pattern.

Tool Count5/5

13 tools is well within the ideal 3-15 range. Each tool maps to a distinct GraphOS capability: documentation access, identity resolution, launch/deployment inspection, health metrics, linting, PQL status, and variant details. No tool feels extraneous, and the count is appropriate for the broad but bounded domain of GraphOS observability and configuration.

Completeness4/5

The surface covers the core GraphOS operations well: deployments (launch tools), traffic health (metrics tools), configuration (variant/PQL/lint), documentation, and identity. A minor gap is the absence of write/management operations (e.g., no tool to trigger a launch, update PQL, or modify variant configuration), meaning the server is read-only in nature. For a read-only observability/health-check server this is acceptable, but an agent could not act on findings. Also no tool to list graphs/variants directly (only via GetMyIdentity).

Resources

Need Help?