A
licenseNot graded
qualityD
maintenanceSearches OpenSearch documentation, blogs, and community forums.
2
MIT
GraphOS MCP Server
Server Details
Search Apollo docs, specs, and best practices
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 52 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.9/5.0
Scored across 32 tools
Disambiguation4/5
Most tools have clearly distinct resource+action purposes, and descriptions explicitly differentiate schema-read variants and metric dimensions. Minor overlap remains between GetOperationMetrics and GetTopOperations, and among the several SDL-reading tools, but misselection is unlikely for a careful agent.
Naming Consistency5/5
All tool names use consistent PascalCase with predictable verb-first patterns such as Get*, Publish*, Delete*, and Run*. ApolloDocsRead/Search and LintSchema/ValidateOperations are minor stylistic variations but do not break the overall convention.
Tool Count2/5
32 tools is heavy for one MCP server and exceeds the typical well-scoped range of 3-15. Although many tools map to distinct GraphOS operations, the surface could be consolidated or split by subdomain.
Completeness4/5
The server covers a broad GraphOS lifecycle: schema publish/delete, checks, linting, metrics, contracts, persisted queries, README, docs, and identity. Missing create-graph/variant operations and contract deletion are minor gaps, likely outside the intended rover-style scope.
Available Tools
32 toolsApolloConnectorsSpecARead-onlyIdempotentInspect
Returns the Apollo Connectors specification for guidance on creating or modifying GraphQL schemas that use @connect or @source.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is well covered. The description adds the scoping context (guidance for @connect/@source schemas) which provides some additional behavioral context. With strong annotation coverage, this is adequate.
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?
Single sentence that's concise and information-dense. It states what it returns and for what purpose with zero waste. The annotation title adds a friendly phrasing but the description itself is tight and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a zero-parameter read-only reference retrieval tool with a rich output schema (Has output schema: true) and comprehensive annotations (readOnly, idempotent, non-destructive), the description covers the essential purpose and use case sufficiently. There are no parameters or side effects to document, making this reasonably complete.
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 tool takes 0 parameters, so there's nothing to explain. Per the rubric, 0 params = baseline 4. The description appropriately adds usage context rather than parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Apollo Connectors specification and for what guidance (creating/modifying GraphQL schemas using @connect or @source). It's a specific verb+resource with clear scope. It doesn't explicitly distinguish from siblings like ApolloDocsRead/Search, but its purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when working with @connect/@source schemas) which helps the agent know when to use it. There are no explicit exclusions or alternatives named, but the annotation title 'Read the Apollo Connectors specification' reinforces the read-only consultative use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ApolloDocsReadARead-onlyIdempotentInspect
Reads an Apollo documentation page by slug in chunks. Use slugs returned by ApolloDocsSearch.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug returned from the ApolloDocsSearch tool | |
| chunkIndex | Yes | The character index to start reading from, will return up to the next 10000 characters |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context by revealing that pages are read in chunks and that valid slugs come from ApolloDocsSearch, which is beyond what the annotations express.
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?
Two short sentences carry the essential meaning with no filler. The core behavior is front-loaded, and the critical workflow dependency on ApolloDocsSearch appears in the second sentence.
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?
For a simple read-only tool with two well-documented parameters, an output schema, and supportive annotations, nothing critical is missing. An agent can correctly invoke it by obtaining a slug from ApolloDocsSearch and supplying a valid chunkIndex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mostly restates the slug dependency already present in the schema, adding little new meaning beyond that 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?
States a specific verb ('Reads'), a specific resource ('Apollo documentation page'), and the key mechanism ('by slug in chunks'). This clearly differentiates it from the sibling ApolloDocsSearch, which is about finding slugs rather than reading pages.
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 direct workflow guidance: use slugs returned by ApolloDocsSearch. It establishes when this tool is appropriate relative to the search sibling, though it does not explicitly mention exclusions or alternative tools beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ApolloDocsSearchBRead-onlyIdempotentInspect
Searches official Apollo documentation for GraphQL, GraphOS, Apollo Router, Apollo Client, MCP Server, schema design, deployment, and Connectors. Returns URLs, slugs, and excerpts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Use terms that would lead to broad result with a maximum of 2 keywords. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, side-effect-free search. The description adds that it returns URLs, slugs, and excerpts, which is useful, but does not disclose pagination, result limits, ordering, or whether results are ranked by relevance. With solid annotations, a 3 is appropriate.
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?
Two sentences, zero waste. States the subject (official Apollo docs), the scope (topic coverage), and the output (URLs, slugs, excerpts). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single-parameter search tool with full schema coverage, a clear output schema, and strong annotations. The description is sufficient for the agent to select and invoke it correctly. The main gap is not clarifying the handoff to ApolloDocsRead for reading full content, but overall this is well-covered for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single query parameter is already documented. The description adds the guidance to use 'broad terms with a maximum of 2 keywords' in the schema itself. Since the schema fully covers the parameter, baseline 3 applies; the description doesn't add extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Searches official Apollo documentation' for named topics. Specifies return values (URLs, slugs, excerpts). Does not explicitly distinguish from the sibling ApolloDocsRead, but the search-vs-read distinction is implied by 'Searches' and returning URLs/slugs/excerpts rather than content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search vs the sibling ApolloDocsRead tool. The description implies search is a discovery step, but never states that after finding a URL you should use ApolloDocsRead to fetch the page content. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DeleteGraphADestructiveInspect
Delete a graph, the same write that rover graph delete performs. This is a soft delete: the data is not removed permanently and Apollo support can restore the graph. Every variant of the graph stops serving, so confirm the graph ID with the user before you call this. Returns null on success. Provide the graph ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A3.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), it discloses that this is a soft delete, that data is not permanently removed, that Apollo support can restore the graph, that all variants stop serving, and that it returns null on success. That is exactly the behavioral context an agent needs before committing a destructive call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences with the destructive scope and the confirm-first warning front-loaded, so the highest-risk information lands first. The trailing 'Provide the graph ID' restates the required parameter already implied earlier, which is mild redundancy but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with an output schema (so return values need not be spelled out), the description covers reversibility, blast radius, confirmation, and the null result. The only real omission is any contrast with the sibling DeleteSubgraph tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single graphId parameter, so the description has to carry the meaning. It says 'Provide the graph ID' and implies an opaque identifier by telling the agent to confirm it with the user, but adds no format, naming, or lookup guidance worth more than a baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a graph') and defines the blast radius ('Every variant of the graph stops serving'), which is clearer than the bare tool name. However, it never distinguishes itself from the sibling DeleteSubgraph, so an agent must infer which deletion target it wants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one concrete precondition ('confirm the graph ID with the user before you call this'), which is genuinely useful for a destructive operation. It offers no when-not guidance and does not name DeleteSubgraph as the alternative for subgraph-level deletion, so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DeleteSubgraphADestructiveInspect
Remove a subgraph from a variant and start composition, the same write that rover subgraph delete performs. Returns the composition errors that the removal causes. This deletes the subgraph from the variant and can break the running router. Set dryRun to true first: the response then reports the composition result that the removal would produce, including updatedGateway, and deletes nothing. Provide the graph ID, the variant name, and the subgraph name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Do not remove the service, but recompose without it and report any errors. | |
| graphId | Yes | ||
| variant | Yes | ||
| subgraphName | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real value beyond them: it states that composition is kicked off, that composition errors are returned, that the running router can break, and that dryRun returns updatedGateway while deleting nothing. Lacks permission/auth requirements, which is the only notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and consequence, then dryRun behavior, then required inputs. Mostly tight, but the clause 'This deletes the subgraph from the variant and can break the running router' partly repeats the opening sentence about removal and composition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, yet the description usefully notes composition errors and updatedGateway for the dryRun path. Combined with the destructive annotation, an agent has enough to invoke this safely; only the three required params lack descriptive depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only dryRun is documented in-schema), and the description's explanation of dryRun largely duplicates it. For the three undocumented required params it merely names them ('provide the graph ID, the variant name, and the subgraph name') without adding format, sourcing, or naming-convention detail an agent couldn't infer from the keys themselves.
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?
States a specific verb (delete/remove) and resource (subgraph from a variant), plus the side effect (start composition). It explicitly frames itself as the equivalent of `rover subgraph delete`, which distinguishes it from siblings like DeleteGraph (whole graph) and PublishSubgraph (write).
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?
Gives concrete operational guidance: 'Set dryRun to true first' and explains the consequence of not doing so (can break the running router). That is clear context for invocation, though it doesn't explicitly contrast against any sibling tool to say when this is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetCheckResultsARead-onlyIdempotentInspect
Read the outcome of one schema check run: the overall status, and for each task in the run the composition errors, lint diagnostics, schema changes with the client operations they affect, downstream variant results, and custom check violations. Use this after GetSchemaChecks gives you a check ID. Provide the graph ID and the check ID. The affected operations are paged with affectedOperationsLimit and affectedOperationsOffset; the change list is capped by the server, and areChangesTruncated reports when that happened.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| checkId | Yes | ||
| graphId | Yes | ||
| affectedOperationsLimit | No | The maximum number of affected queries to return. Must be 50 or fewer.#The maximum number of affected queries to return. Must be 50 or fewer.#The maximum number of affected queries to return. Must be 50 or fewer.#The maximum number of affected queries to return. Must be 50 or fewer. | |
| affectedOperationsOffset | No | How many items to skip before starting to return results. For example, with `limit: 10` and `offset: 10`, you get items 11–20.#How many items to skip before starting to return results. For example, with `limit: 10` and `offset: 10`, you get items 11–20.#How many items to skip before starting to return results. For example, with `limit: 10` and `offset: 10`, you get items 11–20.#How many items to skip before starting to return results. For example, with `limit: 10` and `offset: 10`, you get items 11–20. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description goes beyond them usefully: it explains that affected operations are paged, that the change list is server-capped, and that areChangesTruncated signals truncation. It does not discuss auth/permission requirements or latency, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the call returns before moving to how to invoke it, and each sentence carries distinct information (payload, prerequisite, paging, truncation). The middle enumeration is long and partially duplicates the output schema, but the description remains a single efficient block with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not enumerate return fields, yet it does so and also covers invocation order and paging. Combined with the annotations, an agent has everything needed to call it correctly. The mild redundancy of restating return contents keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (graphId and checkId are undocumented), so the description must compensate. It names affectedOperationsLimit/affectedOperationsOffset and their paging role, and introduces the truncation concept, but omits the 'must be 50 or fewer' constraint and the default offset behavior that the schema supplies. With half the parameters bare in the schema, this is a minimum-viable 3.
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?
States a specific verb and resource ('Read the outcome of one schema check run') and enumerates the concrete payload contents (overall status, composition errors, lint diagnostics, schema changes, downstream variant results, custom check violations). It also distinguishes itself from siblings by tying the call to the GetSchemaChecks -> GetCheckResults workflow, so an agent can identify it without opening another 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?
Gives an explicit prerequisite and sequencing rule ('Use this after GetSchemaChecks gives you a check ID. Provide the graph ID and the check ID.'), which is clear when-to-use guidance. It does not state any exclusions or name a contrasting sibling for cases where results are not what the user wants, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetClientMetricsARead-onlyIdempotentInspect
Traffic broken down by client for a graph over a time window, as compact CSV. Columns: start timestamp, end exclusive timestamp, client name, client version, operation name, request count, request latency p50 ms, request latency p99 ms, request with error count. Answers which clients call a graph, which client versions are still on the wire, and which client drives errors or latency. Clients that do not report apollographql-client-name/-version come back with empty name and version columns. Ranked by orderBy descending: default REQUEST_COUNT (busiest); REQUEST_WITH_ERROR_COUNT for most error-prone, REQUEST_LATENCY_P99_MS for slowest. variantName and operationName scope to one or more variants or operations by exact name (omit for all). Rows are one per client + version + operation, so a busy graph has far more groups than the other metrics tools: scope by operationName or raise limit when a breakdown looks truncated. Keep the default resolution of ENTIRE_RANGE for totals and top-N, which gives one row per group ranked over the whole window. DAY/HOUR/MINUTE give one row per group per bucket ranked within each bucket, so a window total then needs a per-group sum plus a limit big enough to cover every bucket; too small a limit silently undercounts. Only HOUR and MINUTE accept a to of now, so use them for bursts in the last 24 hours. Avoid MONTH: it labels buckets by calendar month, not by the requested window.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | REQUEST_COUNT | |
| resolution | No | The resolution of the time groups for the report. This resolution will affect the range of times that can be used for the 'from' and 'to' timestamps: - For the MINUTE resolution, the total time between 'from' and 'to' must be no more than 1 day, and the 'from' time must be no earlier than 30 days ago. - For the HOUR resolution, the total time between 'from' and 'to' must be no more than 7 days, and the 'from' time must be no earlier than 90 days ago. - For the DAY, MONTH, and ENTIRE_RANGE resolutions, the 'from' time must be no earlier than 549 days ago (approx 18 months), and the 'to' time must be no later than 1 day ago. If these criteria are not met, this will return a REQUEST_INVALID error. | ENTIRE_RANGE |
| variantName | No | ||
| operationName | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes far beyond that by disclosing output specifics (CSV columns, empty client name/version), ranking behavior, row cardinality, silent undercounting when limit is too small, and calendar-month labeling for MONTH. 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?
Although long, every sentence serves a distinct purpose: purpose, output format, default ranking, scoping, row cardinality, resolution behavior, limit warning, temporal constraints, and MONTH caveat. The most important information (purpose and output) is front-loaded, and nothing is redundant.
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 high complexity (8 params, multiple resolutions, ranking metrics, hidden truncation traps), the description is exceptionally complete. It covers behavioral caveats, default selections, and when to adjust parameters. An output schema exists for return values, so the prose need not describe the response structure.
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 description coverage is 50%, and the description substantially compensates. It explains orderBy values and defaults (REQUEST_COUNT default, REQUEST_WITH_ERROR_COUNT for errors, REQUEST_LATENCY_P99_MS for slowest), resolution behavior and defaults, variantName/operationName exact-name scoping, and the limit truncation caveat. This meaningfully extends the raw parameter definitions.
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 opens with a specific verb and resource: 'Traffic broken down by client for a graph over a time window, as compact CSV.' It then enumerates the exact questions it answers (which clients call a graph, which versions are on the wire, which drives errors/latency), clearly distinguishing it from sibling metrics tools like GetOperationMetrics or GetSubgraphMetrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Answers which clients call a graph') and strong when-not-to-use guidance: avoid MONTH, only HOUR/MINUTE accept a 'to' of now, and warns that a busy graph has more groups than other metrics tools so users should scope by operationName or raise limit. This effectively routes the agent to the correct tool without opening sibling schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetContractConfigARead-onlyIdempotentInspect
Read the filter configuration of a contract variant: the tags it includes, the tags it excludes, the source variant it is built from, and a human-readable description of the configuration. This is the same read that rover contract describe performs. A contract variant is a filtered view of another variant's schema, built by including and excluding schema elements by tag. The filter configuration does not include whether unreachable types are hidden. The description states it, so read it there before you update a contract with PublishContract. A variant that is not a contract returns null for the filter configuration. Provide the graph ID and the contract variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds real value beyond them: a non-contract variant returns null, and the returned filter config deliberately omits whether unreachable types are hidden, pointing the agent at the description field instead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is read and what it returns, then moves to caveats and prerequisites. Slightly wordy around 'The description states it, so read it there', but every sentence carries substantive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still covers the null case for non-contract variants and the one field the return does not include, plus the input prerequisites and the PublishContract relationship. Enough for an agent to call and interpret this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the schema gives no parameter meaning; the description partially compensates by mapping the two parameters to 'the graph ID and the contract variant name'. It adds no format, naming conventions, or error semantics for those 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?
Names a specific verb+resource (read the filter configuration of a contract variant) and enumerates exactly what is returned: included tags, excluded tags, source variant, and description. It also defines a contract variant, so the agent can distinguish this from GetVariantDetails and GetGraphSchema.
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?
Gives clear context for use ('the same read that rover contract describe performs') and an explicit downstream condition ('read it there before you update a contract with PublishContract'). It does not compare against an alternative read tool, but the when-to-use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetGraphSchemaARead-onlyIdempotentInspect
Read the schema (SDL) that is currently published to a graph variant, with its hash and publication time. This is the same read that rover graph fetch performs. The response holds the whole document and is not truncated. A large federated graph measured over 800,000 characters, roughly 200,000 tokens, which exceeds the context window of most models. Prefer GetSubgraphSchema, which reads one subgraph at a time, and use this tool only when you need the whole API schema. Provide the graph ID and the variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: the response is untruncated, carries a concrete size benchmark (800,000 characters, ~200,000 tokens), and warns this can exceed most models' context windows. That is exactly the kind of risk disclosure an agent needs before invoking.
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?
Front-loaded with the core purpose, followed by the rover equivalence, the size warning, the alternative, and finally the inputs. Every sentence earns its place and there is no filler.
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?
An output schema exists, so return values need not be re-explained, yet the description still flags hash and publication time plus the document size. Combined with the alternative routing and required inputs, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema carries no parameter documentation. The description only says 'Provide the graph ID and the variant name', which maps the two params to their obvious meanings but adds no format, valid-value, or default guidance (e.g., whether variant accepts 'current'). Minimal compensation for a total coverage gap.
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 states a specific verb and resource: reading the published SDL schema for a graph variant, returning its hash and publication time. It explicitly distinguishes itself from the sibling GetSubgraphSchema and by extension GetSupergraphSchema, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit preference rule ('Prefer GetSubgraphSchema, which reads one subgraph at a time') and the exact condition for using this tool instead ('only when you need the whole API schema'). It also names the required inputs, so both when-to-use and prerequisites are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetLatestLaunchARead-onlyIdempotentInspect
Inspect the most recent launch for a graph variant: status, completion time, subgraph changes, composition errors, and a schema diff summary vs the previous launch (additions/removals/edits/deprecations plus affected operations). Use to assess schema composition health and the impact of recent schema changes. Also returns the latest approved launch for comparison. Provide the graph ID and variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses that the tool also returns the latest approved launch for comparison, which an agent could not infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded in the first clause, followed by a valid usage cue and the input requirement. It is dense but not padded; the mid-sentence enumeration of returned fields is the only part that could be trimmed.
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?
With an output schema present, return values need not be explained, and annotations carry the safety profile, so the remaining burden is purpose, usage, and inputs — all addressed. Nothing required to call this two-parameter read tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are two required parameters, so the description carries the whole burden. 'Provide the graph ID and variant name' names both and hints at the variant's meaning, but adds no format, syntax, or constraint details (e.g., whether variant can be 'current'). Marginal compensation for the coverage gap.
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 opens with a specific verb+resource ('Inspect the most recent launch for a graph variant') and enumerates exactly what is surfaced (status, completion time, subgraph changes, composition errors, schema diff). Adding 'most recent' and the diff-vs-previous-launch scope distinguishes it from the sibling GetLaunch and GetLaunchHistory.
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?
It gives clear intent: 'Use to assess schema composition health and the impact of recent schema changes,' which tells the agent the motivating scenario. It does not, however, state when to prefer GetLaunch or GetLaunchHistory instead, nor any exclusion conditions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetLaunchARead-onlyIdempotentInspect
Inspect a single launch by ID for full detail: status, timestamps, which subgraphs changed, composition errors, and the schema diff summary. Use to drill into a specific launch — e.g. a failed or superseded one found via GetLaunchHistory (pass its id here). Provide the graph ID, variant name, and launch ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes | ||
| launchId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about what the call surfaces (composition errors, schema diff summary, changed subgraphs), which goes beyond the annotations, though it does not cover auth needs or rate limits.
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?
Two sentences, front-loaded with the primary action and return fields, followed by the usage trigger and required inputs. No wasted text.
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?
An output schema exists and annotations cover the safety profile, so the description needn't explain return structure. Combined with full usage routing and all three params named, an agent has everything needed to invoke it correctly.
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?
Schema description coverage is 0%, so the description must carry the param burden, and it names all three (graph ID, variant name, launch ID) plus the provenance of the launch ID from GetLaunchHistory. It does not give format/syntax details, so it is strong but not exhaustive.
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?
States a specific verb and resource ('Inspect a single launch by ID for full detail') and enumerates the fields returned (status, timestamps, changed subgraphs, composition errors, schema diff summary). This clearly separates it from GetLatestLaunch and GetLaunchHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use it ('drill into a specific launch — e.g. a failed or superseded one found via GetLaunchHistory') and names the sibling that produces the required id. Includes the workflow of passing that id here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetLaunchHistoryARead-onlyIdempotentInspect
Retrieve recent launches for a graph variant (most recent first) to detect deployment instability such as repeated failures or frequent superseded launches. Each entry includes the launch id, status, and timestamps, so you can identify a specific launch and drill into it with GetLaunch. Use to assess deployment stability. Provide the graph ID, variant name, and optionally a limit (default 20 most recent launches, max 100 per page) and an offset to page further back.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior. The description adds ordering ('most recent first'), pagination behavior (default 20, max 100 per page, offset), and entry contents (launch id, status, timestamps), which goes beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and ordering, then provides return contents and invocation details. The sentence 'Use to assess deployment stability' partially repeats the earlier stated purpose, so it is not maximally tight, but there is no irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with an output schema, this is nearly complete: parameters, defaults, paging, ordering, and the relationship to GetLaunch are all covered. It falls just short of a 5 by not explicitly disambiguating GetLatestLaunch for cases where only the single newest launch is needed.
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?
With 0% schema description coverage, the description compensates by explaining the optional limit and offset semantics, including defaults and maximum, and naming the required graph ID and variant. It does not elaborate on variant format or graph ID meaning, but it maps every parameter to its role.
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?
States a specific action and resource: 'Retrieve recent launches for a graph variant (most recent first)'. It also names GetLaunch as the downstream drill-down tool, distinguishing this history/list operation from the single-launch siblings GetLaunch and GetLatestLaunch.
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?
Gives an explicit use case: 'Use to assess deployment stability' and 'detect deployment instability such as repeated failures or frequent superseded launches'. It could more explicitly say when to prefer GetLatestLaunch instead, but the plural 'recent launches' and drill-down guidance imply the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetLintResultsARead-onlyIdempotentInspect
Retrieve schema lint violations from a graph's most recent schema checks: each diagnostic's coordinate, severity level, message, rule, and source location, plus error/warning/total/ignored counts. Use to assess schema quality and naming/best-practice violations. Provide the graph ID and optionally a limit (default 5 most recent schema checks).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| graphId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds useful behavioral context beyond that: the shape of returned diagnostics and that the limit selects the N most recent schema checks. It does not mention permissions or pagination, but adds real value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and purpose, followed by the field list and usage. The middle enumeration is dense but earns its place by describing the payload; overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, yet it summarizes them without harm. Inputs and purpose are adequately covered; only auth/permission context is absent, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It clarifies limit as 'default 5 most recent schema checks', which meaningfully explains the parameter, and identifies graphId as the graph to inspect, but omits any format/type detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieving schema lint violations from recent schema checks, and enumerates the diagnostic fields returned. This clearly separates it from generic siblings like GetSchemaChecks or GetCheckResults, though it never names those alternatives explicitly.
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?
Gives a clear use case ('assess schema quality and naming/best-practice violations') and tells the agent what inputs to supply. It stops short of stating when NOT to use it or naming the alternative (e.g., LintSchema to trigger a run vs. this tool to read results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetMyIdentityARead-onlyIdempotentInspect
Resolve the caller's identity from their API key or OAuth token. Call this FIRST when the user asks about "my graph" but has not provided a graph ID. For a graph/service key, me resolves to a Graph: use id as the graphId and variants[].name as the variant for the graph-scoped health-check tools, so the user does not have to supply either. For a user (personal key or OAuth), me resolves to a User instead: there's no single graph, so each org membership's graphs[].id / graphs[].variants[].name lists the graphId/variant options the graph-scoped tools need, across every org the user belongs to. Also handles service-account keys.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: how `me` resolves differently for graph/service keys vs user keys, how to derive graphId and variant, and that service-account keys are handled.
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 earns its place: purpose, when to call, Graph resolution, User resolution, and service-account handling. It is front-loaded with the core action and usage trigger before diving into details.
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?
For a zero-parameter tool with a rich output schema and safety annotations, the description is complete enough. It explains the two resolution paths, how to map results to downstream tool parameters, and covers service-account keys, leaving no critical ambiguity for an agent.
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 tool has zero parameters, so the schema is fully covered and no parameter documentation is needed. The description correctly focuses on the implicit auth context rather than inputs, earning the baseline for parameterless tools.
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 names a specific verb and resource: resolve the caller's identity from their API key or OAuth token. It clearly distinguishes the two possible resolution outcomes (Graph vs User) and is not confusable with any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this FIRST when the user asks about 'my graph' but has not provided a graph ID. It also explains how to use the result with graph-scoped health-check tools, giving concrete routing guidance for both Graph and User cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetOperationMetricsARead-onlyIdempotentInspect
Top operations by usage/health for a graph over a time window, as compact CSV. Columns: start timestamp, end exclusive timestamp, operation name, request count, request latency p50 ms, request latency p99 ms, request with error count. Ranked by orderBy descending: default REQUEST_COUNT (busiest); REQUEST_WITH_ERROR_COUNT for most error-prone, REQUEST_LATENCY_P99_MS for slowest. variantName scopes to one or more variants (omit for all). clients scopes to one or more clients; omit clientVersion to match every version of that client, and use GetClientMetrics to discover the names a graph sees. Keep the default resolution of ENTIRE_RANGE for totals and top-N, which gives one row per operation ranked over the whole window. DAY/HOUR/MINUTE give one row per operation per bucket ranked within each bucket, so a window total then needs a per-operation sum plus a limit big enough to cover every bucket; too small a limit silently undercounts. Only HOUR and MINUTE accept a to of now, so use them for bursts in the last 24 hours. Avoid MONTH: it labels buckets by calendar month, not by the requested window.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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). | |
| clients | No | ||
| graphId | Yes | ||
| orderBy | No | REQUEST_COUNT | |
| resolution | No | The resolution of the time groups for the report. This resolution will affect the range of times that can be used for the 'from' and 'to' timestamps: - For the MINUTE resolution, the total time between 'from' and 'to' must be no more than 1 day, and the 'from' time must be no earlier than 30 days ago. - For the HOUR resolution, the total time between 'from' and 'to' must be no more than 7 days, and the 'from' time must be no earlier than 90 days ago. - For the DAY, MONTH, and ENTIRE_RANGE resolutions, the 'from' time must be no earlier than 549 days ago (approx 18 months), and the 'to' time must be no later than 1 day ago. If these criteria are not met, this will return a REQUEST_INVALID error. | ENTIRE_RANGE |
| variantName | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds substantial behavioral detail: CSV output format, exact columns, default ranking, silent undercounting with small limits, and the MONTH calendar-bucket quirk. No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but dense and purposeful. It front-loads the core purpose and output format, then adds necessary operational context. A small amount of reorganization could improve scannability, but every sentence contributes meaning.
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?
For a tool with 8 parameters and complex resolution/ranking behavior, the description covers the important operational decisions, edge cases, and failure modes. Since an output schema exists, the lack of detailed return-value documentation is acceptable. It is complete enough for an agent to invoke correctly.
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 only 50%, but the description compensates thoroughly. It explains orderBy values and defaults, variantName scoping, clients/clientVersion behavior, resolution trade-offs, limit pitfalls, and the special now constraint for HOUR/MINUTE. This goes well beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns top operations by usage/health for a graph over a time window as compact CSV. It identifies the resource, output format, and ranking semantics. However, it does not explicitly differentiate itself from the sibling tool GetTopOperations, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: keep ENTIRE_RANGE for totals, use HOUR/MINUTE for recent bursts, avoid MONTH, and watch limit undercounting. It also directs users to GetClientMetrics for discovering client names, giving concrete context for when and how to use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetPersistedQueryListStatusARead-onlyIdempotentInspect
Check whether a graph variant has a Persisted Query List (PQL), and return its ID, its name, and its current build (revision and operation count). Pass the ID to PublishPersistedQueries. Use to assess PQL configuration — a production variant with no PQL is a security gap. Provide the graph ID and variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that: what the response contains and the security interpretation of a missing PQL. It does not discuss pagination or multi-variant batching, but the output schema covers return shape.
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?
Three tight sentences, with the core purpose front-loaded, followed by workflow routing and usage context. No filler; every sentence carries information.
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?
For a simple two-parameter read tool with an output schema and full annotation coverage, the description supplies purpose, workflow linkage, and usage rationale. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden. 'Provide the graph ID and variant name' tells the agent what both required parameters represent, which is useful, but adds no format, casing, or example detail beyond a restatement of the parameter names. Baseline 3 is appropriate for this partial compensation.
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?
States a specific verb and resource ('Check whether a graph variant has a PQL') and enumerates exactly what is returned (ID, name, build revision and operation count). It is clearly distinguishable from siblings and explicitly names the related PublishPersistedQueries tool.
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?
Gives concrete when-to-use context ('Use to assess PQL configuration — a production variant with no PQL is a security gap') and the downstream workflow ('Pass the ID to PublishPersistedQueries'). No explicit when-not or sibling alternatives are offered, but no other sibling returns PQL status, so the routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetReadmeARead-onlyIdempotentInspect
Read the README of a graph variant, with the time it was last updated and who updated it. This is the same read that rover readme fetch performs. The README is the Markdown document shown on the variant's page in GraphOS Studio. Provide the graph ID and the variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds return-behavior context beyond annotations: it says the response includes the time of last update and who updated it, which is useful and not conveyed by annotations. It doesn't discuss error cases or permissions, but with annotations carrying the safety profile, this is solid.
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?
Three tight sentences, front-loaded with the verb and resource, followed by context and inputs. Every sentence adds distinct value without redundancy or filler.
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 presence of an output schema, the description appropriately does not explain return structure, but does highlight what the response carries (last updated time and author). With read-only annotations, simple params, and full output schema, the description covers everything an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema names parameters (graphId, variant) without describing them. The description compensates partially by saying 'Provide the graph ID and the variant name', clarifying intent but adding no format or constraint details (e.g., ID format, variant casing). With only two simple required params, a baseline 3 is appropriate.
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?
States a specific verb (Read) and resource (README of a graph variant), and distinguishes itself from the sibling PublishReadme (write counterpart). The description also explains what the README actually is ('the Markdown document shown on the variant's page in GraphOS Studio'), making the resource concrete rather than abstract.
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?
Provides a concrete routing signal by equating the tool to `rover readme fetch`, which tells the agent exactly when this is the right tool. It also states the identifying inputs required (graph ID and variant name). However, it does not explicitly call out exclusions or name the sibling it differs from (e.g., PublishReadme for writes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetSchemaChecksARead-onlyIdempotentInspect
List past schema checks for a graph: each check's ID, status, timestamps, the subgraph it checked, the variant it ran against, the commit, and the status of each task in the check, plus the total count for the filter. Use this to find a check, then pass its ID to GetCheckResults for failure details. Provide the graph ID. Optionally filter by status (PASSED, FAILED, PENDING), subgraph names, branches, variants, authors, or check IDs, and page with limit and offset.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| limit | No | ||
| offset | No | ||
| status | No | ||
| authors | No | ||
| graphId | Yes | ||
| branches | No | ||
| variants | No | ||
| subgraphs | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the text. The description adds some value by noting the filter total count and paging behavior, but much of the return-shape detail duplicates the output schema. With annotations carrying the behavioral burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the listing behavior, followed by the routing sentence and then the parameter inventory. Every sentence carries information, though the parameter sentence is long and enumerates fields the schema already names, which slightly dilutes density.
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?
For a 9-parameter, filter-and-paginate list tool, the definition covers the required argument, the full filter set including enum values, paging, the total-count behavior, and the handoff to GetCheckResults, while the output schema covers return shape. Nothing an agent needs to call it correctly is 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 description coverage is 0% across 9 parameters, so the description must carry the whole load and it largely does: it documents the required graph ID, the status filter with its exact enum values (PASSED, FAILED, PENDING), and the subgraph, branch, variant, author, check-ID, limit and offset filters. This meaningfully compensates for both the missing schema descriptions and the missing enum hints, adding syntax the schema lacks.
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?
States a specific verb and resource ('List past schema checks for a graph') and then enumerates exactly what each item contains (ID, status, timestamps, subgraph, variant, commit, task statuses, total count), so an agent knows precisely what it gets back. It also names the sibling relationship to GetCheckResults, distinguishing itself from that tool without opening either 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?
Gives explicit usage context: 'Use this to find a check, then pass its ID to GetCheckResults for failure details,' which routes the agent between the two tools. It does not, however, contrast itself with RunSchemaCheck or state when-not to use this list, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetSubgraphMetricsARead-onlyIdempotentInspect
Top subgraphs/connectors by traffic/health for a graph over a time window, as compact CSV. 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); FETCH_WITH_ERRORS_COUNT for most error-prone, FETCH_LATENCY_P99_MS for slowest. variantName scopes to one or more variants (omit for all). subgraphName scopes to one or more subgraphs by exact name (omit for all); pattern/substring matching is not supported. clients scopes to the fetches driven by one or more clients; omit clientVersion to match every version of that client, and use GetClientMetrics to discover the names a graph sees. Keep the default resolution of ENTIRE_RANGE for totals and top-N, which gives one row per subgraph ranked over the whole window. DAY/HOUR/MINUTE give one row per subgraph per bucket ranked within each bucket, so a window total then needs a per-subgraph sum plus a limit big enough to cover every bucket; too small a limit silently undercounts. Only HOUR and MINUTE accept a to of now, so use them for bursts in the last 24 hours. Avoid MONTH: it labels buckets by calendar month, not by the requested window.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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). | |
| clients | No | ||
| graphId | Yes | ||
| orderBy | No | FETCH_COUNT | |
| resolution | No | The resolution of the time groups for the report. This resolution will affect the range of times that can be used for the 'from' and 'to' timestamps: - For the MINUTE resolution, the total time between 'from' and 'to' must be no more than 1 day, and the 'from' time must be no earlier than 30 days ago. - For the HOUR resolution, the total time between 'from' and 'to' must be no more than 7 days, and the 'from' time must be no earlier than 90 days ago. - For the DAY, MONTH, and ENTIRE_RANGE resolutions, the 'from' time must be no earlier than 549 days ago (approx 18 months), and the 'to' time must be no later than 1 day ago. If these criteria are not met, this will return a REQUEST_INVALID error. | ENTIRE_RANGE |
| variantName | No | ||
| subgraphName | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety burden is covered. The description goes far beyond annotations by disclosing output columns, CSV formatting, ranking/orderBy semantics, exact-match-only subgraph filtering, silent undercounting when limit is too small, and MONTH's calendar-bucket behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but nearly every sentence adds a needed caveat or parameter semantic, and the critical output columns are front-loaded. It could be slightly improved with structured bullets or shorter sentences, but given the tool has 9 parameters and several non-obvious resolution behaviors, the length is largely justified.
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?
For a high-complexity analytics tool, the description covers the essential invocation decisions: default resolution, ranking metrics, scoping filters, client discovery via a sibling tool, and resolution-specific constraints like the now limitation and monthly bucketing. The required graphId and from/to timestamp remain schema-obvious, and an output schema exists, so nothing critical is missing for correct selection and invocation.
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 description coverage is only 44%, so the description carries most of the parameter-meaning burden, and it does so thoroughly. It explains orderBy values and defaults, variantName scoping, subgraphName exact-match limitations, clients/clientVersion behavior, resolution bucket semantics, and the limit undercount risk. This is strong compensation for the sparse schema descriptions.
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 identifies the resource (top subgraphs/connectors by traffic/health for a graph), the action (Get), and the response format (compact CSV with explicit columns). It even differentiates itself from the sibling GetClientMetrics by positioning that tool as the way to discover client names, so an agent can distinguish this tool without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides unusually explicit usage guidance: keep ENTIRE_RANGE for totals and top-N, use DAY/HOUR/MINUTE per-bucket with a caveat about summing and limit, use HOUR/MINUTE for bursts in the last 24 hours, and avoid MONTH because of calendar-month labeling. It also directs the agent to GetClientMetrics when client names are unknown. This is model-quality routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetSubgraphSchemaARead-onlyIdempotentInspect
Read one subgraph's published schema (SDL) from a variant, with its routing URL, revision, and last update time. This is the same read that rover subgraph fetch performs. Read one subgraph at a time: a whole supergraph document is much larger and can pass the token limit of the model. Provide the graph ID, the variant name, and the subgraph name. Use GetVariantDetails first if you do not know the subgraph names.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes | ||
| subgraphName | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds real context beyond that: the tool returns routing URL, revision, and last update time, and it warns that reading a whole supergraph risks exceeding the model's token limit. It does not describe pagination or error behavior.
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?
Four tight sentences, front-loaded with what is returned, then the token-limit rationale, then the required inputs, then the discovery alternative. Every sentence carries information; none restates the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is not strictly needed, yet the description briefly notes the returned fields. It also names the three required params and the prerequisite discovery tool. The only gap is that the 0%-covered parameters get no format detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry parameter meaning. It enumerates the three required inputs in prose ('the graph ID, the variant name, and the subgraph name'), which maps them to the schema, but adds no format, casing, or valid-value guidance. It compensates only partially for the documentation gap.
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?
States a specific verb and resource ('Read one subgraph's published schema (SDL) from a variant') and enumerates the returned fields (routing URL, revision, last update time). It implicitly distinguishes itself from GetSupergraphSchema by warning that the whole supergraph document is much larger, so an agent can pick the right tool without opening 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?
Gives a clear precondition-with-alternative: 'Use GetVariantDetails first if you do not know the subgraph names.' It also implicitly steers away from whole-supergraph reads via the token-limit note. It does not explicitly contrast with the sibling GetGraphSchema, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetSupergraphSchemaARead-onlyIdempotentInspect
Read the composed supergraph schema (SDL) for a graph variant, with the composition ID and any composition errors. This is the same read that rover supergraph fetch performs. A supergraph schema is the single schema that composition builds from every subgraph, and it carries federation directives that the API schema does not. The response holds the whole document and is not truncated, and a supergraph schema is larger than the API schema it produces. Expect the same order of size: a large federated graph exceeds 800,000 characters, roughly 200,000 tokens. A variant that is not federated has no composition result, and the tool returns null for it rather than an empty document. Provide the graph ID and the variant name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), the description adds substantial value: it warns the response is untruncated and can exceed 800,000 characters (~200,000 tokens), and that a non-federated variant returns null rather than an empty document. These are non-obvious behaviors an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then context, then size/edge-case warnings, then parameter reminder. Efficient overall, though the size warning is stated slightly redundantly across two sentences ('is not truncated... larger than the API schema' followed by 'Expect the same order of size...').
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?
An output schema exists, so return-value formatting need not be described, yet the description still covers size, null behavior, and error inclusion. Nothing an agent needs to invoke this correctly in a complex federated-graph context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters. The description says 'Provide the graph ID and the variant name,' which identifies both params but adds essentially no semantics beyond their names (no format, no acquisition guidance). It slightly compensates for the empty schema but leaves gaps, so a 3 is appropriate.
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?
States a specific verb and resource ('Read the composed supergraph schema (SDL) for a graph variant') and distinguishes it from related schemas by noting it 'carries federation directives that the API schema does not.' An agent can tell it apart from GetGraphSchema/GetSubgraphSchema without opening any 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?
Gives clear context by equating it to `rover supergraph fetch` and contrasting supergraph vs API schema output, which implicitly routes the agent. However it never explicitly names the alternative sibling tools (GetGraphSchema, GetSubgraphSchema) or states when NOT to use this one, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetTopOperationsARead-onlyIdempotentInspect
Identify the most-used operations on a graph variant for a time range, with request counts, types, and signatures. Use to find high-traffic operations, detect unused operations, and prioritize findings by traffic impact. Provide graph ID, variant, and a from/to time range (ISO 8601 timestamps; to must be at least 6 hours before now), plus an optional limit (default 50). This report is rate limited.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The ending timestamp for the report. - Must be in the format: 2025-01-01T08:00:00Z (ISO 8601). - Must be at least 6 hours from the current time. - The duration between 'from' and 'to' must not exceed 31 days. | |
| from | Yes | The starting timestamp for the report. - Must be in the format: 2025-01-01T00:00:00Z (ISO 8601). - Must be within the last 549 days. - The duration between 'from' and 'to' must not exceed 31 days. | |
| limit | No | Maximum number of records to return (default: 10) | |
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds a useful behavioral note that the report is rate limited and restates the freshness constraint on the `to` timestamp. No contradiction with the annotations is present.
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?
Three sentences, front-loaded with the core function, then use cases, then parameter/behavioral notes. Each sentence earns its place and the description remains compact despite covering multiple important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, use cases, required parameters, time-range constraints, and rate limiting, and an output schema exists. However, the contradictory limit default and the lack of graphId/variant semantics leave the agent with partially conflicting and incomplete invocation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names graphId, variant, from/to, and limit, but graphId and variant lack semantic explanation in both the schema and description. More seriously, the description states the limit default is 50 while the schema declares a default of 10, creating conflicting guidance for invocation.
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 opens with a specific verb and resource: 'Identify the most-used operations on a graph variant for a time range,' and names the returned data (request counts, types, signatures). This clearly conveys what the tool does and distinguishes it from the broader sibling metric/report tools.
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?
It explicitly states when to use the tool: find high-traffic operations, detect unused operations, and prioritize findings by traffic impact. It does not name alternative tools or exclusion conditions, so it falls short of full when/not-when guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GetVariantDetailsARead-onlyIdempotentInspect
Retrieve metadata for a graph variant: its identifier, federation version, the URL of its GraphQL endpoint, and its subgraph inventory (names only). Use this to assess a variant's composition setup, such as subgraph inventory and federation version compliance. Provide the graph ID and variant name (e.g., "production").
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds beyond that by clarifying the scope of returned data, particularly that subgraph inventory is 'names only' and that this is a metadata lookup rather than a mutation.
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?
Two tightly written sentences with no filler. The first sentence states the operation and results; the second provides the use case and required parameter guidance. Everything earns its place.
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 low complexity (two required string parameters), the existing output schema, and annotations covering read-only/idempotent behavior, the description supplies the essential selection and invocation context. Nothing critical is missing for an agent to decide when to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage, so the description must compensate. It does identify the two required parameters and gives an example for variant ('production'), but it does not explain what a graphId is, how to obtain it, or acceptable formats for either parameter.
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 opens with a specific verb and resource: 'Retrieve metadata for a graph variant,' and enumerates the exact fields returned: identifier, federation version, endpoint URL, and subgraph inventory. This makes the tool's purpose immediately distinguishable from sibling tools focused on launches, metrics, or lint results.
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 usage context: 'Use this to assess a variant's composition setup, such as subgraph inventory and federation version compliance.' It does not explicitly name alternatives or exclusion conditions, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LintSchemaARead-onlyIdempotentInspect
Lint a GraphQL schema document against the graph's lint rules and return each diagnostic's coordinate, severity level, message, rule, and source location, plus the error, warning, total, and ignored counts. This is the same check that rover graph lint and rover subgraph lint run. Nothing is published and no state changes. Provide the graph ID and the schema as SDL. Optionally provide baseSdl to report only the diagnostics that the new schema introduces against that base.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sdl | Yes | The schema to lint. | |
| baseSdl | No | The schema to diff rule violations against, if not provided the full set of rule violations will be returned for the proposed sdl. | |
| graphId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description still adds value by asserting explicitly that 'Nothing is published and no state changes', and by naming the CLI check equivalence and the baseSdl diff semantics.
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?
Three tight sentences: what it does and returns, the CLI equivalence and safety note, then the parameter guidance. Front-loaded and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be re-explained; the description still usefully lists the diagnostic fields and count fields. For a 3-param, read-only tool this is near-complete, missing only a description for graphId and explicit sibling-routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: sdl and baseSdl are documented in the schema, but graphId has no description anywhere. The description adds the SDL format requirement ('as SDL') and the baseSdl diff behavior, which roughly matches the schema text rather than exceeding it. Baseline 3 is appropriate.
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?
States a specific verb (lint) and resource (a GraphQL schema document), and describes the return payload's shape. Distinguishes itself from siblings like RunSchemaCheck and ValidateOperations by stating it runs the same rules as `rover graph lint`/`rover subgraph lint`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by drawing an equivalence to `rover graph lint` and by describing baseSdl as an optional diff mode, but never states when to prefer this tool over RunSchemaCheck or GetLintResults. The when/when-not is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PublishContractADestructiveInspect
Create or update a contract variant and start a launch for it, the same write that rover contract publish performs. A contract variant is a filtered view of another variant's schema, built by including and excluding schema elements by tag. The filter configuration replaces the previous one in full, so send the complete include and exclude lists rather than only the tags you want to change. The same applies to hideUnreachableTypes, which has no default: when you update a contract, pass the value it has now. GetContractConfig states that value in its description. Returns the contract variant and a link to the launch, or the error messages that stopped it. Provide the graph ID, the contract variant name, the source variant, the include and exclude tag lists, and whether to hide unreachable types.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| exclude | Yes | ||
| graphId | Yes | ||
| include | Yes | ||
| sourceVariant | No | The graphRef of the variant the contract will be derived from, e.g. `my-graph@production`. Once set, this value cannot be changed. | |
| initiateLaunch | No | Whether a launch and schema publish should be initiated after updating configuration. Defaults to `true`. | |
| contractVariant | Yes | The name of the contract variant, e.g. `public-api`. Once set, this value cannot be changed. | |
| hideUnreachableTypes | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a destructive, open-world write, and the description adds real behavioral context on top: the include/exclude configuration is replaced in full rather than merged, hideUnreachableTypes is mandatory with no default, and the result is either the variant plus a launch link or the errors that stopped the launch. The destructive-replace semantics are exactly the kind of trait an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the CLI equivalent, then the semantics that matter most (full replacement, no default). The closing sentence enumerating the required inputs is partly redundant with the schema, but overall the passage is dense and every other sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no elaboration, and the description still notes them briefly. It covers the non-obvious behaviors (full-replace filter, mandatory hideUnreachableTypes) that a 7-parameter mutation needs, though it does not touch on permission or auth requirements.
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?
Schema coverage is only 43%, so the description has to carry weight, and it does: it explains that include/exclude are complete replacement tag lists and that hideUnreachableTypes must be supplied with its current value. It enumerates the expected inputs (graph ID, contract variant name, source variant, include/exclude lists, hideUnreachableTypes), though it omits mention of initiateLaunch, which is only documented in the schema.
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?
States a specific verb and resource ('Create or update a contract variant and start a launch for it') and anchors it to a known CLI operation (`rover contract publish`). It goes further by defining what a contract variant actually is (a filtered view of another variant's schema), which distinguishes it from the Publish* siblings that operate on graphs and subgraphs.
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?
Gives clear operating context: the filter config is a full replacement, so callers must send complete lists, and hideUnreachableTypes has no default so the current value must be passed. It also routes the agent to GetContractConfig to obtain that value. It stops short of explicitly naming when to prefer this over PublishGraphSchema/PublishSubgraph, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PublishGraphSchemaADestructiveInspect
Publish a schema to a graph variant, the same write that rover graph publish performs. Use this for a monograph; use PublishSubgraph for one subgraph of a federated graph. Returns a result code, whether the publish succeeded, a human-readable message, and the hash of the published schema. This changes the schema registry and can change what clients see. Run RunSchemaCheck first to see the effect on client operations. Provide the graph ID, the variant name, and the schema as SDL. Optionally provide the git branch and commit to label the publication.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | ||
| commit | No | ||
| graphId | Yes | ||
| variant | Yes | ||
| schemaDocument | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the mutation risk is covered structurally. The description adds genuinely useful context beyond that: it changes the schema registry and can change what clients see, and it lists the returned result code, success flag, message, and published schema hash. It does not, however, mention permission/auth requirements, which would be valuable for a destructive registry write.
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?
Five tight sentences, front-loaded with purpose and alternative first, then behavioral consequences, then prerequisite, then parameters. Every sentence carries distinct information with no restatement of the tool name or annotations.
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?
An output schema exists so return values need not be detailed, yet the description briefly summarizes them anyway. Combined with the sibling differentiation, destructive side-effect disclosure, prerequisite check, and per-parameter meaning, an agent has everything needed to invoke this correctly.
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?
Schema description coverage is 0% and there are 5 parameters, so the description must compensate, and it largely does: it names graphId, variant, and schemaDocument (as SDL), and explains that branch and commit are optional labels for the publication. This adds real meaning over the bare anyOf string types, though it could be more precise about accepted ID/format shapes.
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?
Starts with a specific verb+resource ('Publish a schema to a graph variant') and immediately ties it to the equivalent CLI command. It explicitly distinguishes itself from the closest sibling by naming PublishSubgraph and the monograph-vs-federated condition, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use this tool (monograph) versus the named alternative (PublishSubgraph for one subgraph of a federated graph), and adds a prerequisite workflow: run RunSchemaCheck first to see the effect on client operations. Both the selection condition and the ordering guidance are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PublishPersistedQueriesADestructiveInspect
Publish operations to a persisted query list, the same write that rover persisted-queries publish performs. A persisted query list is the set of operations a router accepts when it is configured to reject anything else. Operations you do not mention stay in the list unchanged: pass operations to add or replace entries, and remove to drop them. Returns the new revision and the total operation count, or reports that nothing changed. Use GetPersistedQueryListStatus to find the list ID and its current revision. Provide the graph ID and the persisted query list ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | ||
| remove | No | ||
| graphId | Yes | ||
| operations | No | ||
| allowOverwrittenOperations | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, but the description adds essential context the annotations cannot: add/replace vs remove semantics and that unspecified operations are preserved, plus return info (new revision, total count, or no-change). It does not explain what 'allowOverwrittenOperations' controls, which is a notable behavioral gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences that are front-loaded with the action and then progressively add semantics, returns, and workflow routing. Every sentence earns its place, though the sentence listing required IDs is slightly redundant with the math of required parameters.
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?
Covers the operation's purpose, its non-obvious merge semantics, the return contract, the prerequisite discovery step, and the required identifiers. With the output schema present, the description does not need to detail return values further, and it remains complete for an agent to call this destructive mutation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does explain the roles of 'operations' and 'remove' and what happens when they are omitted. However, the most semantically risky parameter for this mutation, 'allowOverwrittenOperations', is never mentioned, and 'graphId'/'listId' only appear as a generic instruction to provide them.
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?
States a specific verb and resource ('Publish operations to a persisted query list') and further anchors it by equating it to the known CLI command 'rover persisted-queries publish'. It even explains what a persisted query list is, so an agent can distinguish it from siblings like PublishGraphSchema, PublishSubgraph, PublishReadme, and PublishContract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it, includes the workflow prerequisite ('Use GetPersistedQueryListStatus to find the list ID and its current revision'), names the sibling that supplies required inputs, and clarifies the non-destructive semantics of omission ('Operations you do not mention stay in the list unchanged').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PublishReadmeADestructiveInspect
Replace the README of a graph variant, the same write that rover readme publish performs. The README is the Markdown document shown on the variant's page in GraphOS Studio. The new text replaces the whole README, so read the current one with GetReadme first if you intend to keep any of it. Provide the graph ID, the variant name, and the full README text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| readme | Yes | The full new text of the README, as a Markdown-formatted string. | |
| graphId | Yes | ||
| variant | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description goes further by explaining the blast radius — the new text replaces the whole README, not a merge. It does not mention required scopes/permissions, which is a minor gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying information, with the action and its destructive scope front-loaded. Slightly verbose around the Studio explanation, which is helpful context but not strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write with an output schema available, the description covers purpose, scope of replacement, and preparation, so an agent can call it correctly. Missing auth/permission expectations and any note on variant validity keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (just the readme field); graphId and variant have no schema descriptions. The description partially compensates by naming all three inputs and clarifying the README must be the full text, but it adds no format or identifier semantics for graphId/variant.
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 opens with a specific verb+resource ('Replace the README of a graph variant') and anchors it to a known CLI operation, so the agent knows exactly what side effect this tool performs. It is clearly distinguishable from the read-only sibling GetReadme.
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?
It gives concrete preparatory guidance ('read the current one with GetReadme first if you intend to keep any of it'), which is genuinely actionable. It doesn't state explicit when-not-to-use conditions or contrast with other publish tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PublishSubgraphADestructiveInspect
Publish a subgraph schema to a variant and start composition, the same write that rover subgraph publish performs. Returns whether the subgraph was created or updated, any composition errors, and the launch that started. This changes the schema registry and can change what the router serves. Run RunSubgraphCheck first to see the effect on client operations. Provide the graph ID, the variant name, the subgraph name, and the schema as SDL. Provide the routing URL when you add a subgraph or move its endpoint. Optionally provide a revision label and the git branch and commit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sdl | Yes | ||
| url | No | ||
| branch | No | ||
| commit | No | ||
| graphId | Yes | ||
| variant | Yes | ||
| revision | No | ||
| subgraphName | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds real context: it changes the schema registry and 'can change what the router serves', plus it enumerates what the response contains (created vs updated, composition errors, launch). It does not cover permission/auth requirements or failure modes for invalid variants, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and blast radius, and most sentences earn their place. The later enumeration ('Provide the graph ID, the variant name...') mildly restates required fields already implied, making it slightly verbose though still readable.
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?
With an output schema present, return values need not be explained, yet the description summarizes them anyway. Combined with the prerequisite routing, the side-effect warning, and full parameter coverage for a 0%-documented schema, an agent has everything needed to call it correctly.
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 description coverage is 0%, so the description must carry the full burden, and it does: it accounts for all 8 parameters including graphId, variant, subgraphName, sdl ('as SDL'), url, revision, branch, and commit. It even adds conditional meaning to url that the bare schema cannot express.
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?
States a specific verb and resource ('Publish a subgraph schema to a variant and start composition') and anchors it to a known equivalent ('the same write that rover subgraph publish performs'). This clearly distinguishes it from siblings like PublishGraphSchema, PublishContract, and RunSubgraphCheck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the prerequisite alternative ('Run RunSubgraphCheck first to see the effect on client operations') and gives the condition for supplying the optional url ('when you add a subgraph or move its endpoint'). Both when-to-use and parameter-conditional guidance are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RunSchemaCheckAInspect
Start a schema check of a proposed schema against a variant, the same check that rover graph check starts. Use this for a monograph or for a whole supergraph schema; use RunSubgraphCheck for one subgraph. The check runs in the background, so this returns a workflow ID and a Studio URL, not a result. Pass the returned workflowID to GetCheckResults to read the outcome. Provide the graph ID, the variant name, and the proposed schema as SDL. Optionally provide the git branch and commit to label the run in Studio.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | ||
| commit | No | ||
| graphId | Yes | ||
| variant | Yes | ||
| proposedSchema | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, non-read-only, open-world behavior. The description adds critical context beyond annotations: the check runs in the background, returns a workflow ID and Studio URL rather than a result, and requires a handoff to GetCheckResults. This fully discloses the async workflow.
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 four tight sentences, front-loaded with the core action and followed by alternatives, operational behavior, and parameter guidance. Every sentence adds necessary information without padding.
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?
For an async check-start tool with an output schema, the description covers when to use it, what it returns, how to retrieve results, and all parameter roles. Nothing required to call it correctly is 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 description coverage is 0%, so the description must carry the full burden. It does: it maps the three required parameters (graph ID, variant, proposed schema as SDL) and two optional ones (branch and commit to label the run in Studio), making parameter meaning clear despite the empty schema.
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 states a specific action (start a schema check) on a specific resource (proposed schema against a variant) and explicitly distinguishes it from RunSubgraphCheck. An agent can immediately identify what the tool does without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names when to use this tool (monograph or whole supergraph schema) and when to use the alternative (RunSubgraphCheck for one subgraph). It also clarifies the follow-up tool GetCheckResults, leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RunSubgraphCheckAInspect
Start a schema check of one proposed subgraph schema against a variant, the same check that rover subgraph check starts. The check runs in the background, so this returns a workflow ID and a Studio URL, not a result. Pass the returned workflowID to GetCheckResults to read the outcome. Provide the graph ID, the variant name, the subgraph name, and the proposed subgraph schema as SDL. Optionally provide the git branch and commit to label the run in Studio.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | ||
| commit | No | ||
| graphId | Yes | ||
| variant | Yes | ||
| subgraphName | Yes | ||
| proposedSchema | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true), it discloses the crucial async trait: the check runs in the background and returns a workflow ID and Studio URL rather than a result. This is exactly the behavioral context an agent needs and that the annotations do not convey.
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?
Front-loaded with the core action, then the async caveat, then parameter guidance. Every sentence adds distinct value with no repetition.
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?
Despite an output schema existing, the description proactively explains the return (workflow ID + Studio URL) and the follow-up tool (GetCheckResults), so the agent knows the full call-and-continue workflow.
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 description coverage is 0%, so the description carries the full burden. It names and explains every parameter: graph ID, variant, subgraph name, proposed schema as SDL, plus optional branch and commit for Studio labeling.
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 states a specific verb (start a schema check) and resource (one proposed subgraph schema against a variant), and anchors it to a known CLI equivalent (`rover subgraph check`). This distinguishes it from the composite-level RunSchemaCheck sibling.
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?
It routes the agent explicitly to GetCheckResults for reading the outcome, which is strong alternative guidance. It does not explicitly contrast with the sibling RunSchemaCheck or state exclusions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ValidateOperationsARead-onlyIdempotentInspect
Validate client GraphQL operations against a variant's published schema and return each problem's type (FAILURE, WARNING, INVALID), code, description, and the name of the operation it came from. This is the same check that rover client check runs. Nothing is published and no state changes. Provide the graph ID and the operations, each one a body and an optional name. Optionally name the variant to validate against; the default is "current".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| variant | No | current | |
| operations | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| errors | No | |
| extensions | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description reinforces this ('Nothing is published and no state changes') and additionally discloses the shape of the result (problem type, code, description, operation name), which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and return shape, then covers the equivalence to `rover client check` and the parameters. Dense but no wasted sentences; only mildly long for a three-parameter tool.
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?
An output schema exists, yet the description still summarizes the returned problem fields, and it covers all inputs including the variant default and the no-side-effect guarantee. An agent has everything needed to invoke it correctly.
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?
Schema description coverage is 0%, so the description must carry the burden, and it largely does: it explains graphId, the operations array (each a body plus an optional name), and the variant with its 'current' default. It adds the default value semantics that the schema states only as a bare 'current' string, though it could say more about operation body format.
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?
States a specific verb (validate) and resource (client GraphQL operations against a variant's published schema) and returns a well-defined artifact (problem type/code/description/operation name). This is clearly distinguishable from schema-level siblings like LintSchema, RunSchemaCheck, and RunSubgraphCheck, which target schemas rather than client operations.
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?
Provides strong context: it is 'the same check that `rover client check` runs', nothing is published and no state changes, and the variant defaults to 'current'. However, it never explicitly contrasts when to use this versus RunSchemaCheck or LintSchema, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
GetLatestLaunch1 field changed- changed
Output schema / properties / data / properties / graph / anyOfPrevious value: -[ - { - "properties": { - "variant": { - "anyOf": [ - { - "properties": { - "latestApprovedLaunch": { - "anyOf": [ - { - "properties": { - "completedAt": { - "anyOf": [ - { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - { - "type": "null" - } - ], - "description": "The timestamp when the launch completed. This value is null until the launch completes." - }, - "id": { - "description": "The unique identifier for this launch.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "status": { - "$ref": "#/definitions/LaunchStatus", - "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." - } - }, - "required": [ - "id", - "status" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Latest approved launch for the variant, and what is served through Uplink." - }, - "latestLaunch": { - "anyOf": [ - { - "properties": { - "completedAt": { - "anyOf": [ - { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - { - "type": "null" - } - ], - "description": "The timestamp when the launch completed. This value is null until the launch completes." - }, - "id": { - "description": "The unique identifier for this launch.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "publication": { - "anyOf": [ - { - "properties": { - "compositionResult": { - "anyOf": [ - { - "properties": { - "errors": { - "description": "A list of errors that occurred during composition. Errors mean that Apollo was unable to compose the graph variant's subgraphs into a supergraph schema. If any errors are present, gateways / routers are not updated.", - "items": { - "properties": { - "code": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "A machine-readable error code." - }, - "locations": { - "description": "Source locations related to the error.", - "items": { - "anyOf": [ - { - "properties": { - "column": { - "description": "Column number.", - "type": "integer" - }, - "line": { - "description": "Line number.", - "type": "integer" - } - }, - "required": [ - "line", - "column" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "type": "array" - }, - "message": { - "description": "A human-readable message describing the error.", - "type": "string" - } - }, - "required": [ - "message", - "locations" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "errors" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The result of federated composition executed for this publication. This result includes either a supergraph schema or error details, depending on whether composition succeeded. This value is null when the publication is for a non-federated graph." - }, - "diffToPrevious": { - "anyOf": [ - { - "properties": { - "affectedQueries": { - "anyOf": [ - { - "items": { - "properties": { - "id": { - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "isValid": { - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ], - "description": "Determines if this query validates against the proposed schema" - }, - "markedAsIgnored": { - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ], - "description": "Whether this operation was ignored and its severity was downgraded for that reason" - }, - "markedAsSafe": { - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ], - "description": "Whether the changes were marked as safe and its severity was downgraded for that reason" - }, - "name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Name provided for the operation, which can be empty string if it is an anonymous operation" - } - }, - "required": [ - "id" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "description": "Operations affected by all changes in the diff." - }, - "changeSummary": { - "description": "Numeric summaries for each type of change in the diff.", - "properties": { - "field": { - "description": "Counts for changes to fields of objects, input objects, and interfaces.", - "properties": { - "additions": { - "description": "Number of changes that are additions of fields to object, interface, and input types.", - "type": "integer" - }, - "edits": { - "description": "Number of changes that are field edits. This includes fields changing type and any field\ndeprecation and description changes, but also includes any argument changes and any input object\nfield changes.", - "type": "integer" - }, - "removals": { - "description": "Number of changes that are removals of fields from object, interface, and input types.", - "type": "integer" - } - }, - "required": [ - "additions", - "removals", - "edits" - ], - "type": "object" - }, - "total": { - "description": "Counts for all changes.", - "properties": { - "additions": { - "description": "Number of changes that are additions. This includes adding types, adding fields to object, input\nobject, and interface types, adding values to enums, adding members to interfaces and unions, and\nadding arguments.", - "type": "integer" - }, - "deprecations": { - "description": "Number of changes that are new usages of the @deprecated directive.", - "type": "integer" - }, - "edits": { - "description": "Number of changes that are edits. This includes types changing kind, fields and arguments\nchanging type, arguments changing default value, and any description changes. This also includes\nedits to @deprecated reason strings.", - "type": "integer" - }, - "removals": { - "description": "Number of changes that are removals. This includes removing types, removing fields from object,\ninput object, and interface types, removing values from enums, removing members from interfaces\nand unions, and removing arguments. This also includes removing @deprecated usages.", - "type": "integer" - } - }, - "required": [ - "additions", - "removals", - "edits", - "deprecations" - ], - "type": "object" - } - }, - "required": [ - "total", - "field" - ], - "type": "object" - } - }, - "required": [ - "changeSummary" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "A schema diff comparing against the schema from the most recent previous successful publication." - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "A specific publication of a graph variant pertaining to this launch." - }, - "status": { - "$ref": "#/definitions/LaunchStatus", - "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." - }, - "subgraphChanges": { - "anyOf": [ - { - "items": { - "properties": { - "name": { - "description": "The subgraph's name.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - } - }, - "required": [ - "name" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "description": "A list of subgraph changes that are included in this launch." - } - }, - "required": [ - "id", - "status" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Latest launch for the variant, whether successful or not." - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "variant": { + "anyOf": [ + { + "properties": { + "latestApprovedLaunch": { + "anyOf": [ + { + "properties": { + "completedAt": { + "anyOf": [ + { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + { + "type": "null" + } + ], + "description": "The timestamp when the launch completed. This value is null until the launch completes." + }, + "id": { + "description": "The unique identifier for this launch.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "status": { + "$ref": "#/definitions/LaunchStatus", + "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Latest approved launch for the variant, and what is served through Uplink." + }, + "latestLaunch": { + "anyOf": [ + { + "properties": { + "build": { + "anyOf": [ + { + "properties": { + "result": { + "anyOf": [ + { + "properties": { + "errorMessages": { + "description": "A list of all errors that occurred during the failed build.", + "items": { + "properties": { + "code": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "failedStep": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "locations": { + "items": { + "properties": { + "column": { + "description": "Column number.", + "type": "integer" + }, + "line": { + "description": "Line number.", + "type": "integer" + } + }, + "required": [ + "line", + "column" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + } + }, + "required": [ + "message", + "locations" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "errorMessages" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The result of the build. This value is null until the build completes." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The associated build for this launch (a build includes schema composition and contract filtering). This value is null until the build is initiated." + }, + "completedAt": { + "anyOf": [ + { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + { + "type": "null" + } + ], + "description": "The timestamp when the launch completed. This value is null until the launch completes." + }, + "id": { + "description": "The unique identifier for this launch.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "publication": { + "anyOf": [ + { + "properties": { + "diffToPrevious": { + "anyOf": [ + { + "properties": { + "affectedQueries": { + "anyOf": [ + { + "items": { + "properties": { + "id": { + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "isValid": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Determines if this query validates against the proposed schema" + }, + "markedAsIgnored": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether this operation was ignored and its severity was downgraded for that reason" + }, + "markedAsSafe": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether the changes were marked as safe and its severity was downgraded for that reason" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Name provided for the operation, which can be empty string if it is an anonymous operation" + } + }, + "required": [ + "id" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Operations affected by all changes in the diff." + }, + "changeSummary": { + "description": "Numeric summaries for each type of change in the diff.", + "properties": { + "field": { + "description": "Counts for changes to fields of objects, input objects, and interfaces.", + "properties": { + "additions": { + "description": "Number of changes that are additions of fields to object, interface, and input types.", + "type": "integer" + }, + "edits": { + "description": "Number of changes that are field edits. This includes fields changing type and any field\ndeprecation and description changes, but also includes any argument changes and any input object\nfield changes.", + "type": "integer" + }, + "removals": { + "description": "Number of changes that are removals of fields from object, interface, and input types.", + "type": "integer" + } + }, + "required": [ + "additions", + "removals", + "edits" + ], + "type": "object" + }, + "total": { + "description": "Counts for all changes.", + "properties": { + "additions": { + "description": "Number of changes that are additions. This includes adding types, adding fields to object, input\nobject, and interface types, adding values to enums, adding members to interfaces and unions, and\nadding arguments.", + "type": "integer" + }, + "deprecations": { + "description": "Number of changes that are new usages of the @deprecated directive.", + "type": "integer" + }, + "edits": { + "description": "Number of changes that are edits. This includes types changing kind, fields and arguments\nchanging type, arguments changing default value, and any description changes. This also includes\nedits to @deprecated reason strings.", + "type": "integer" + }, + "removals": { + "description": "Number of changes that are removals. This includes removing types, removing fields from object,\ninput object, and interface types, removing values from enums, removing members from interfaces\nand unions, and removing arguments. This also includes removing @deprecated usages.", + "type": "integer" + } + }, + "required": [ + "additions", + "removals", + "edits", + "deprecations" + ], + "type": "object" + } + }, + "required": [ + "total", + "field" + ], + "type": "object" + } + }, + "required": [ + "changeSummary" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "A schema diff comparing against the schema from the most recent previous successful publication." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "A specific publication of a graph variant pertaining to this launch." + }, + "status": { + "$ref": "#/definitions/LaunchStatus", + "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." + }, + "subgraphChanges": { + "anyOf": [ + { + "items": { + "properties": { + "name": { + "description": "The subgraph's name.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "A list of subgraph changes that are included in this launch." + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Latest launch for the variant, whether successful or not." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Changed
GetLaunch1 field changed- changed
Output schema / properties / data / properties / graph / anyOfPrevious value: -[ - { - "properties": { - "variant": { - "anyOf": [ - { - "properties": { - "launch": { - "anyOf": [ - { - "properties": { - "completedAt": { - "anyOf": [ - { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - { - "type": "null" - } - ], - "description": "The timestamp when the launch completed. This value is null until the launch completes." - }, - "createdAt": { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - "id": { - "description": "The unique identifier for this launch.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "publication": { - "anyOf": [ - { - "properties": { - "compositionResult": { - "anyOf": [ - { - "properties": { - "errors": { - "description": "A list of errors that occurred during composition. Errors mean that Apollo was unable to compose the graph variant's subgraphs into a supergraph schema. If any errors are present, gateways / routers are not updated.", - "items": { - "properties": { - "code": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "A machine-readable error code." - }, - "locations": { - "description": "Source locations related to the error.", - "items": { - "anyOf": [ - { - "properties": { - "column": { - "description": "Column number.", - "type": "integer" - }, - "line": { - "description": "Line number.", - "type": "integer" - } - }, - "required": [ - "line", - "column" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "type": "array" - }, - "message": { - "description": "A human-readable message describing the error.", - "type": "string" - } - }, - "required": [ - "message", - "locations" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "errors" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The result of federated composition executed for this publication. This result includes either a supergraph schema or error details, depending on whether composition succeeded. This value is null when the publication is for a non-federated graph." - }, - "diffToPrevious": { - "anyOf": [ - { - "properties": { - "changeSummary": { - "description": "Numeric summaries for each type of change in the diff.", - "properties": { - "total": { - "description": "Counts for all changes.", - "properties": { - "additions": { - "description": "Number of changes that are additions. This includes adding types, adding fields to object, input\nobject, and interface types, adding values to enums, adding members to interfaces and unions, and\nadding arguments.", - "type": "integer" - }, - "deprecations": { - "description": "Number of changes that are new usages of the @deprecated directive.", - "type": "integer" - }, - "edits": { - "description": "Number of changes that are edits. This includes types changing kind, fields and arguments\nchanging type, arguments changing default value, and any description changes. This also includes\nedits to @deprecated reason strings.", - "type": "integer" - }, - "removals": { - "description": "Number of changes that are removals. This includes removing types, removing fields from object,\ninput object, and interface types, removing values from enums, removing members from interfaces\nand unions, and removing arguments. This also includes removing @deprecated usages.", - "type": "integer" - } - }, - "required": [ - "additions", - "removals", - "edits", - "deprecations" - ], - "type": "object" - } - }, - "required": [ - "total" - ], - "type": "object" - } - }, - "required": [ - "changeSummary" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "A schema diff comparing against the schema from the most recent previous successful publication." - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "A specific publication of a graph variant pertaining to this launch." - }, - "status": { - "$ref": "#/definitions/LaunchStatus", - "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." - }, - "subgraphChanges": { - "anyOf": [ - { - "items": { - "properties": { - "name": { - "description": "The subgraph's name.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - } - }, - "required": [ - "name" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "description": "A list of subgraph changes that are included in this launch." - } - }, - "required": [ - "id", - "status", - "createdAt" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Retrieve a launch for this variant by ID." - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "variant": { + "anyOf": [ + { + "properties": { + "launch": { + "anyOf": [ + { + "properties": { + "build": { + "anyOf": [ + { + "properties": { + "result": { + "anyOf": [ + { + "properties": { + "errorMessages": { + "description": "A list of all errors that occurred during the failed build.", + "items": { + "properties": { + "code": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "failedStep": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "locations": { + "items": { + "properties": { + "column": { + "description": "Column number.", + "type": "integer" + }, + "line": { + "description": "Line number.", + "type": "integer" + } + }, + "required": [ + "line", + "column" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + } + }, + "required": [ + "message", + "locations" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "errorMessages" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The result of the build. This value is null until the build completes." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The associated build for this launch (a build includes schema composition and contract filtering). This value is null until the build is initiated." + }, + "completedAt": { + "anyOf": [ + { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + { + "type": "null" + } + ], + "description": "The timestamp when the launch completed. This value is null until the launch completes." + }, + "createdAt": { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + "id": { + "description": "The unique identifier for this launch.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "publication": { + "anyOf": [ + { + "properties": { + "diffToPrevious": { + "anyOf": [ + { + "properties": { + "changeSummary": { + "description": "Numeric summaries for each type of change in the diff.", + "properties": { + "total": { + "description": "Counts for all changes.", + "properties": { + "additions": { + "description": "Number of changes that are additions. This includes adding types, adding fields to object, input\nobject, and interface types, adding values to enums, adding members to interfaces and unions, and\nadding arguments.", + "type": "integer" + }, + "deprecations": { + "description": "Number of changes that are new usages of the @deprecated directive.", + "type": "integer" + }, + "edits": { + "description": "Number of changes that are edits. This includes types changing kind, fields and arguments\nchanging type, arguments changing default value, and any description changes. This also includes\nedits to @deprecated reason strings.", + "type": "integer" + }, + "removals": { + "description": "Number of changes that are removals. This includes removing types, removing fields from object,\ninput object, and interface types, removing values from enums, removing members from interfaces\nand unions, and removing arguments. This also includes removing @deprecated usages.", + "type": "integer" + } + }, + "required": [ + "additions", + "removals", + "edits", + "deprecations" + ], + "type": "object" + } + }, + "required": [ + "total" + ], + "type": "object" + } + }, + "required": [ + "changeSummary" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "A schema diff comparing against the schema from the most recent previous successful publication." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "A specific publication of a graph variant pertaining to this launch." + }, + "status": { + "$ref": "#/definitions/LaunchStatus", + "description": "The launch's status. If a launch is superseded, its status remains `LAUNCH_INITIATED`. To check for a superseded launch, use `supersededAt`." + }, + "subgraphChanges": { + "anyOf": [ + { + "items": { + "properties": { + "name": { + "description": "The subgraph's name.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "A list of subgraph changes that are included in this launch." + } + }, + "required": [ + "id", + "status", + "createdAt" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Retrieve a launch for this variant by ID." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." + } + }, + "type": "object" + }, + { + "type": "null" + } +]
1 tool update
- Changed
GetCheckResults1 field changed- changed
Output schema / properties / data / properties / graph / anyOfPrevious value: -[ - { - "properties": { - "checkWorkflow": { - "anyOf": [ - { - "properties": { - "baseVariant": { - "anyOf": [ - { - "properties": { - "name": { - "description": "The variant's name (e.g., `staging`).", - "type": "string" - } - }, - "required": [ - "name" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The variant provided as a base to check against. Only the differences from the\nbase schema will be tested in operations checks." - }, - "completedAt": { - "anyOf": [ - { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - { - "type": "null" - } - ], - "description": "The timestamp when the check workflow completed." - }, - "createdAt": { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - "gitContext": { - "anyOf": [ - { - "properties": { - "commit": { - "anyOf": [ - { - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - { - "type": "null" - } - ] - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Contextual parameters supplied by the runtime environment where the check was run." - }, - "id": { - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "implementingServiceName": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The name of the implementing service that was responsible for triggering the validation." - }, - "startedAt": { - "anyOf": [ - { - "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" - }, - { - "type": "null" - } - ], - "description": "The timestamp when the check workflow started." - }, - "status": { - "$ref": "#/definitions/CheckWorkflowStatus", - "description": "Overall status of the workflow, based on the underlying task statuses." - }, - "tasks": { - "description": "The set of check tasks associated with this workflow, e.g. composition, operations, etc.", - "items": { - "properties": { - "__typename": { - "description": "The typename of this object", - "type": "string" - }, - "coreSchemaModified": { - "description": "Whether the build's output supergraph core schema differs from that of the active publish for\nthe workflow's variant at the time this field executed (NOT at the time the check workflow\nstarted).", - "type": "boolean" - }, - "hasWarnings": { - "description": "True if this Proposal check passed with warnings, otherwise false.", - "type": "boolean" - }, - "id": { - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "proposalCoverage": { - "$ref": "#/definitions/ProposalCoverage", - "description": "Indicates the level of coverage a check's changeset is in approved Proposals. PENDING while Check is still running." - }, - "result": { - "anyOf": [ - { - "properties": { - "violations": { - "items": { - "properties": { - "coordinate": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The schema coordinate of this rule violation as defined by RFC:\n\t\thttps://github.com/graphql/graphql-wg/blob/main/rfcs/SchemaCoordinates.md\n\t\tOptional for violations that aren't specific to a single schema element" - }, - "level": { - "$ref": "#/definitions/ViolationLevel", - "description": "The violation level for the rule." - }, - "message": { - "description": "A human-readable message describing the rule violation, rendered as markdown in Apollo Studio. Maximum length: 512 characters.", - "type": "string" - }, - "rule": { - "description": "The rule being violated. This is used to group multiple violations together in Studio. Max character length is 128.", - "type": "string" - } - }, - "required": [ - "level", - "message", - "rule" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "violations" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "results": { - "anyOf": [ - { - "items": { - "properties": { - "blocking": { - "description": "Whether the downstream check workflow blocks the upstream check workflow from completing.", - "type": "boolean" - }, - "downstreamGraphID": { - "description": "The ID of the graph that the downstream variant belongs to.", - "type": "string" - }, - "downstreamVariantName": { - "description": "The name of the downstream variant.", - "type": "string" - }, - "failsUpstreamWorkflow": { - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ], - "description": "Whether the downstream check workflow is causing the upstream check workflow to fail. This occurs\nwhen the downstream check workflow is both blocking and failing. This may be null while the\ndownstream check workflow is pending." - } - }, - "required": [ - "blocking", - "downstreamGraphID", - "downstreamVariantName" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "description": "A list of results for all downstream checks triggered as part of the source variant's checks workflow.\nThis value is null if the task hasn't been initialized yet, or if the build task fails (the build task is a\nprerequisite to this task). This value is _not_ null _while_ the task is running. The returned list is empty\nif the source variant has no downstream variants." - }, - "severityLevel": { - "$ref": "#/definitions/ProposalChangeMismatchSeverity", - "description": "The configured severity at the time the check was run. If the check failed, this is the severity that should be shown. While this Check is PENDING defaults to Service's severityLevel." - }, - "status": { - "$ref": "#/definitions/CheckWorkflowTaskStatus", - "description": "The status of this task. All tasks start with the PENDING status while initializing. If any\n prerequisite task fails, then the task status becomes BLOCKED. Otherwise, if all prerequisite\n tasks pass, then this task runs (still having the PENDING status). Once the task completes, the\n task status will become either PASSED or FAILED." - }, - "targetURL": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "A studio UI url to view the details of this check workflow task" - } - }, - "required": [ - "id", - "status" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "id", - "status", - "createdAt", - "tasks" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Get a check workflow for this graph by its ID" - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "checkWorkflow": { + "anyOf": [ + { + "properties": { + "baseVariant": { + "anyOf": [ + { + "properties": { + "name": { + "description": "The variant's name (e.g., `staging`).", + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The variant provided as a base to check against. Only the differences from the\nbase schema will be tested in operations checks." + }, + "completedAt": { + "anyOf": [ + { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + { + "type": "null" + } + ], + "description": "The timestamp when the check workflow completed." + }, + "createdAt": { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + "gitContext": { + "anyOf": [ + { + "properties": { + "commit": { + "anyOf": [ + { + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Contextual parameters supplied by the runtime environment where the check was run." + }, + "id": { + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "implementingServiceName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The name of the implementing service that was responsible for triggering the validation." + }, + "startedAt": { + "anyOf": [ + { + "description": "ISO 8601, extended format with nanoseconds, Zulu (or \"[+-]seconds\" as a string or number relative to now)" + }, + { + "type": "null" + } + ], + "description": "The timestamp when the check workflow started." + }, + "status": { + "$ref": "#/definitions/CheckWorkflowStatus", + "description": "Overall status of the workflow, based on the underlying task statuses." + }, + "tasks": { + "description": "The set of check tasks associated with this workflow, e.g. composition, operations, etc.", + "items": { + "properties": { + "__typename": { + "description": "The typename of this object", + "type": "string" + }, + "compositionResult": { + "anyOf": [ + { + "properties": { + "errors": { + "description": "A list of errors that occurred during composition. Errors mean that Apollo was unable to compose the graph variant's subgraphs into a supergraph schema. If any errors are present, gateways / routers are not updated.", + "items": { + "properties": { + "code": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "A machine-readable error code." + }, + "locations": { + "description": "Source locations related to the error.", + "items": { + "anyOf": [ + { + "properties": { + "column": { + "description": "Column number.", + "type": "integer" + }, + "line": { + "description": "Line number.", + "type": "integer" + } + }, + "required": [ + "line", + "column" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "type": "array" + }, + "message": { + "description": "A human-readable message describing the error.", + "type": "string" + } + }, + "required": [ + "message", + "locations" + ], + "type": "object" + }, + "type": "array" + }, + "graphCompositionID": { + "description": "The unique ID for this instance of composition.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "required": [ + "graphCompositionID", + "errors" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "An old version of buildResult that returns a very old GraphQL type that generally should be\navoided. This field will soon be deprecated." + }, + "coreSchemaModified": { + "description": "Whether the build's output supergraph core schema differs from that of the active publish for\nthe workflow's variant at the time this field executed (NOT at the time the check workflow\nstarted).", + "type": "boolean" + }, + "customResult": { + "anyOf": [ + { + "properties": { + "violations": { + "items": { + "properties": { + "coordinate": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The schema coordinate of this rule violation as defined by RFC:\n\t\thttps://github.com/graphql/graphql-wg/blob/main/rfcs/SchemaCoordinates.md\n\t\tOptional for violations that aren't specific to a single schema element" + }, + "level": { + "$ref": "#/definitions/ViolationLevel", + "description": "The violation level for the rule." + }, + "message": { + "description": "A human-readable message describing the rule violation, rendered as markdown in Apollo Studio. Maximum length: 512 characters.", + "type": "string" + }, + "rule": { + "description": "The rule being violated. This is used to group multiple violations together in Studio. Max character length is 128.", + "type": "string" + } + }, + "required": [ + "level", + "message", + "rule" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "violations" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "hasWarnings": { + "description": "True if this Proposal check passed with warnings, otherwise false.", + "type": "boolean" + }, + "id": { + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "lintResult": { + "anyOf": [ + { + "properties": { + "diagnostics": { + "description": "The set of lint rule violations found in the schema.", + "items": { + "properties": { + "coordinate": { + "description": "The schema coordinate of this diagnostic.", + "type": "string" + }, + "level": { + "$ref": "#/definitions/LintDiagnosticLevel", + "description": "The graph's configured level for the rule." + }, + "message": { + "description": "The message describing the rule violation.", + "type": "string" + }, + "rule": { + "$ref": "#/definitions/LintRule", + "description": "The lint rule being violated." + }, + "sourceLocations": { + "description": "The human readable position in the file of the rule violation.", + "items": { + "properties": { + "end": { + "anyOf": [ + { + "properties": { + "column": { + "type": "integer" + }, + "line": { + "type": "integer" + } + }, + "required": [ + "line", + "column" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "start": { + "anyOf": [ + { + "properties": { + "column": { + "type": "integer" + }, + "line": { + "type": "integer" + } + }, + "required": [ + "line", + "column" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "subgraphName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "coordinate", + "level", + "message", + "rule", + "sourceLocations" + ], + "type": "object" + }, + "type": "array" + }, + "stats": { + "description": "Stats generated from the resulting diagnostics.", + "properties": { + "errorsCount": { + "description": "Total number of lint errors.", + "type": "integer" + }, + "ignoredCount": { + "description": "Total number of lint rules ignored.", + "type": "integer" + }, + "totalCount": { + "description": "Total number of lint rules violated.", + "type": "integer" + }, + "warningsCount": { + "description": "Total number of lint warnings.", + "type": "integer" + } + }, + "required": [ + "errorsCount", + "warningsCount", + "totalCount", + "ignoredCount" + ], + "type": "object" + } + }, + "required": [ + "diagnostics", + "stats" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "operationsResult": { + "anyOf": [ + { + "properties": { + "affectedQueries": { + "anyOf": [ + { + "items": { + "properties": { + "displayName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Name to display to the user for the operation" + }, + "id": { + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "isValid": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Determines if this query validates against the proposed schema" + }, + "markedAsIgnored": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether this operation was ignored and its severity was downgraded for that reason" + }, + "markedAsSafe": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether the changes were marked as safe and its severity was downgraded for that reason" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Name provided for the operation, which can be empty string if it is an anonymous operation" + } + }, + "required": [ + "id" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Operations affected by all changes in diff" + }, + "areChangesTruncated": { + "description": "Indicates whether the changes for this operation check were truncated due to their large quantity.", + "type": "boolean" + }, + "changeSummary": { + "description": "Summary/counts for all changes in diff", + "properties": { + "total": { + "description": "Counts for all changes.", + "properties": { + "additions": { + "description": "Number of changes that are additions. This includes adding types, adding fields to object, input\nobject, and interface types, adding values to enums, adding members to interfaces and unions, and\nadding arguments.", + "type": "integer" + }, + "deprecations": { + "description": "Number of changes that are new usages of the @deprecated directive.", + "type": "integer" + }, + "edits": { + "description": "Number of changes that are edits. This includes types changing kind, fields and arguments\nchanging type, arguments changing default value, and any description changes. This also includes\nedits to @deprecated reason strings.", + "type": "integer" + }, + "removals": { + "description": "Number of changes that are removals. This includes removing types, removing fields from object,\ninput object, and interface types, removing values from enums, removing members from interfaces\nand unions, and removing arguments. This also includes removing @deprecated usages.", + "type": "integer" + } + }, + "required": [ + "additions", + "removals", + "edits", + "deprecations" + ], + "type": "object" + } + }, + "required": [ + "total" + ], + "type": "object" + }, + "changes": { + "description": "List of schema changes with associated affected clients and operations", + "items": { + "properties": { + "category": { + "$ref": "#/definitions/ChangeCategory", + "description": "Indication of the category of the change (e.g. addition, removal, edit)." + }, + "code": { + "description": "Indicates the type of change that was made, and to what (e.g., 'TYPE_REMOVED').", + "type": "string" + }, + "description": { + "description": "A human-readable description of the change.", + "type": "string" + }, + "severity": { + "$ref": "#/definitions/ChangeSeverity", + "description": "The severity of the change (e.g., `FAILURE` or `NOTICE`)" + } + }, + "required": [ + "severity", + "code", + "category", + "description" + ], + "type": "object" + }, + "type": "array" + }, + "checkSeverity": { + "$ref": "#/definitions/ChangeSeverity", + "description": "Indication of the success of the change, either failure, warning, or notice." + }, + "numberOfAffectedOperations": { + "description": "Number of affected operations that are neither marked as SAFE or IGNORED.", + "type": "integer" + }, + "numberOfCheckedOperations": { + "description": "Number of operations that were validated during schema diff", + "type": "integer" + }, + "totalNumberOfAffectedOperations": { + "description": "Total number of affected operations including ones marked SAFE or IGNORED.", + "type": "integer" + }, + "totalNumberOfChanges": { + "description": "Total number of schema changes, excluding any truncation.", + "type": "integer" + } + }, + "required": [ + "checkSeverity", + "numberOfCheckedOperations", + "totalNumberOfChanges", + "areChangesTruncated", + "numberOfAffectedOperations", + "totalNumberOfAffectedOperations", + "changeSummary", + "changes" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The result of the operations check. This will be null when the task is initializing or running,\nor when the build task fails (which is a prerequisite task to this one)." + }, + "proposalCoverage": { + "$ref": "#/definitions/ProposalCoverage", + "description": "Indicates the level of coverage a check's changeset is in approved Proposals. PENDING while Check is still running." + }, + "results": { + "anyOf": [ + { + "items": { + "properties": { + "blocking": { + "description": "Whether the downstream check workflow blocks the upstream check workflow from completing.", + "type": "boolean" + }, + "downstreamGraphID": { + "description": "The ID of the graph that the downstream variant belongs to.", + "type": "string" + }, + "downstreamVariantName": { + "description": "The name of the downstream variant.", + "type": "string" + }, + "failsUpstreamWorkflow": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether the downstream check workflow is causing the upstream check workflow to fail. This occurs\nwhen the downstream check workflow is both blocking and failing. This may be null while the\ndownstream check workflow is pending." + } + }, + "required": [ + "blocking", + "downstreamGraphID", + "downstreamVariantName" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "A list of results for all downstream checks triggered as part of the source variant's checks workflow.\nThis value is null if the task hasn't been initialized yet, or if the build task fails (the build task is a\nprerequisite to this task). This value is _not_ null _while_ the task is running. The returned list is empty\nif the source variant has no downstream variants." + }, + "severityLevel": { + "$ref": "#/definitions/ProposalChangeMismatchSeverity", + "description": "The configured severity at the time the check was run. If the check failed, this is the severity that should be shown. While this Check is PENDING defaults to Service's severityLevel." + }, + "status": { + "$ref": "#/definitions/CheckWorkflowTaskStatus", + "description": "The status of this task. All tasks start with the PENDING status while initializing. If any\n prerequisite task fails, then the task status becomes BLOCKED. Otherwise, if all prerequisite\n tasks pass, then this task runs (still having the PENDING status). Once the task completes, the\n task status will become either PASSED or FAILED." + }, + "targetURL": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "A studio UI url to view the details of this check workflow task" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "status", + "createdAt", + "tasks" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Get a check workflow for this graph by its ID" + } + }, + "type": "object" + }, + { + "type": "null" + } +]
19 tool updates
- Added
DeleteGraph - Added
DeleteSubgraph - Added
GetCheckResults - Added
GetContractConfig - Added
GetGraphSchema - Changed
GetPersistedQueryListStatus1 field changed- changed
Output schema / properties / data / properties / graph / anyOfPrevious value: -[ - { - "properties": { - "variant": { - "anyOf": [ - { - "properties": { - "persistedQueryList": { - "anyOf": [ - { - "properties": { - "currentBuild": { - "description": "The current build of this PQL.", - "properties": { - "revision": { - "description": "The revision of this Persisted Query List. Revision 0 is the initial empty list; each publish increments the revision by 1.", - "type": "integer" - }, - "totalOperationsInList": { - "description": "The total number of operations in the list after this build. Compare to PersistedQueriesPublish.operationCounts.", - "type": "integer" - } - }, - "required": [ - "revision", - "totalOperationsInList" - ], - "type": "object" - } - }, - "required": [ - "currentBuild" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The Persisted Query List linked to this variant, if any." - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "variant": { + "anyOf": [ + { + "properties": { + "persistedQueryList": { + "anyOf": [ + { + "properties": { + "currentBuild": { + "description": "The current build of this PQL.", + "properties": { + "revision": { + "description": "The revision of this Persisted Query List. Revision 0 is the initial empty list; each publish increments the revision by 1.", + "type": "integer" + }, + "totalOperationsInList": { + "description": "The total number of operations in the list after this build. Compare to PersistedQueriesPublish.operationCounts.", + "type": "integer" + } + }, + "required": [ + "revision", + "totalOperationsInList" + ], + "type": "object" + }, + "id": { + "description": "The immutable ID for this Persisted Query List.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "name": { + "description": "The list's name; can be changed and does not need to be unique.", + "type": "string" + } + }, + "required": [ + "id", + "name", + "currentBuild" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The Persisted Query List linked to this variant, if any." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Provides details of the graph variant with the provided `name`, if a variant\nwith that name exists for this graph. Otherwise, returns null.\n\n For a list of _all_ variants associated with a graph, use `Graph.variants` instead." + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Added
GetReadme - Added
GetSchemaChecks - Added
GetSubgraphSchema - Added
GetSupergraphSchema - Added
LintSchema - Added
PublishContract - Added
PublishGraphSchema - Added
PublishPersistedQueries - Added
PublishReadme - Added
PublishSubgraph - Added
RunSchemaCheck - Added
RunSubgraphCheck - Added
ValidateOperations
1 tool update
- Changed
GetMyIdentity1 field changed- changed
Output schema / properties / data / properties / me / anyOfPrevious value: -[ - { - "properties": { - "__typename": { - "description": "The typename of this object", - "type": "string" - }, - "account": { - "anyOf": [ - { - "properties": { - "id": { - "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "name": { - "description": "Name of the organization, which can change over time and isn't unique.", - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The organization that this graph belongs to." - }, - "id": { - "description": "The identity's identifier, which is unique among objects of its type.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "memberships": { - "description": "A list of the user's memberships in Apollo Studio organizations.", - "items": { - "properties": { - "account": { - "description": "The organization that the user belongs to.", - "properties": { - "graphs": { - "description": "Graphs belonging to this organization.", - "items": { - "properties": { - "id": { - "description": "The graph's globally unique identifier.", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "name": { - "type": "string" - }, - "variants": { - "description": "A list of the variants for this graph.", - "items": { - "properties": { - "name": { - "description": "The variant's name (e.g., `staging`).", - "type": "string" - } - }, - "required": [ - "name" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "id", - "name", - "variants" - ], - "type": "object" - }, - "type": "array" - }, - "id": { - "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "name": { - "description": "Name of the organization, which can change over time and isn't unique.", - "type": "string" - } - }, - "required": [ - "id", - "name", - "graphs" - ], - "type": "object" - } - }, - "required": [ - "account" - ], - "type": "object" - }, - "type": "array" - }, - "name": { - "description": "The identity's human-readable name.", - "type": "string" - }, - "organization": { - "anyOf": [ - { - "properties": { - "id": { - "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", - "oneOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ] - }, - "name": { - "description": "Name of the organization, which can change over time and isn't unique.", - "type": "string" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The organization this service account belongs to." - }, - "variants": { - "description": "A list of the variants for this graph.", - "items": { - "properties": { - "name": { - "description": "The variant's name (e.g., `staging`).", - "type": "string" - } - }, - "required": [ - "name" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "id", - "name" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "__typename": { + "description": "The typename of this object", + "type": "string" + }, + "account": { + "anyOf": [ + { + "properties": { + "id": { + "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "name": { + "description": "Name of the organization, which can change over time and isn't unique. If the organization has no company\nname set, this falls back to the organization's ID.", + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The organization that this graph belongs to." + }, + "id": { + "description": "The identity's identifier, which is unique among objects of its type.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "memberships": { + "description": "A list of the user's memberships in Apollo Studio organizations.", + "items": { + "properties": { + "account": { + "description": "The organization that the user belongs to.", + "properties": { + "graphs": { + "description": "Graphs belonging to this organization.", + "items": { + "properties": { + "id": { + "description": "The graph's globally unique identifier.", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "name": { + "type": "string" + }, + "variants": { + "description": "A list of the variants for this graph.", + "items": { + "properties": { + "name": { + "description": "The variant's name (e.g., `staging`).", + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "variants" + ], + "type": "object" + }, + "type": "array" + }, + "id": { + "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "name": { + "description": "Name of the organization, which can change over time and isn't unique. If the organization has no company\nname set, this falls back to the organization's ID.", + "type": "string" + } + }, + "required": [ + "id", + "name", + "graphs" + ], + "type": "object" + } + }, + "required": [ + "account" + ], + "type": "object" + }, + "type": "array" + }, + "name": { + "description": "The identity's human-readable name.", + "type": "string" + }, + "organization": { + "anyOf": [ + { + "properties": { + "id": { + "description": "Globally unique identifier, which isn't guaranteed stable (can be changed by administrators).", + "oneOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "name": { + "description": "Name of the organization, which can change over time and isn't unique. If the organization has no company\nname set, this falls back to the organization's ID.", + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The organization this service account belongs to." + }, + "variants": { + "description": "A list of the variants for this graph.", + "items": { + "properties": { + "name": { + "description": "The variant's name (e.g., `staging`).", + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + { + "type": "null" + } +]
Related MCP Connectors
Search the Anthid trading API reference, schemas, and product pages.
Search SORACOM documentation: service guides, FAQ, API references, IoT recipes, etc.
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables searching and retrieving Reflex documentation, including full-text search, code examples, error analysis, changelog, migration guides, API reference, component props, and recipes.143MIT
- AlicenseAqualityDmaintenanceSearch and fetch MCP protocol documentation using BM25 search with weighted scoring and stemming.242 npm2MIT
- FlicenseNot gradedqualityDmaintenanceEnables searching and fetching documentation pages from a wide range of programming languages, frameworks, game engines, and tools. Supports multiple sources and returns relevant documentation snippets.1-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.