Reads an Apollo documentation page by slug in chunks. Use slugs returned by ApolloDocsSearch.
| 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 |
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| errors | No | ||
| extensions | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the chunking behavior ('in chunks' and 'up to 10000 characters'), which is useful but minimal. It doesn't explain paging semantics beyond what the parameter schema already covers — how to know when to stop paginating, or what happens at the end of a document. With annotations present, the bar is lower, but the description could add more context about the iteration pattern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, directly informative. Every word earns its place — states the operation, the input requirement, and the data dependency on the sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, annotations covering safety, and 100% parameter schema coverage, which offloads most burden. However, the chunked-pagination pattern is the core behavioral aspect and the description only hints at it without explaining how an agent should know it's reached the end or how many chunks exist. For a paginated reader with a sibling search tool, slightly more workflow guidance would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (slug and chunkIndex) are already documented in the schema with descriptions. The description adds minimal value — it mentions 'in chunks' and the dependency on ApolloDocsSearch for slugs, but doesn't explain the pagination iteration pattern (e.g., increment chunkIndex until a shorter result indicates end of doc). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Reads an Apollo documentation page by slug in chunks') which clearly identifies what the tool does. It distinguishes it from ApolloDocsSearch (which finds pages, this reads them), though it doesn't explicitly name the sibling for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells the agent to use slugs returned by ApolloDocsSearch, establishing a prerequisite dependency and implying the read-after-search workflow. It doesn't explicitly state when not to use it or name alternatives, but the 'Use slugs returned by ApolloDocsSearch' guidance gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct resource and action: docs (search/read), launches (history/get/latest), metrics (operations/subgraphs/top ops), config checks (PQL/lint/variant), and identity resolution. There is no meaningful overlap — GetLaunchHistory, GetLaunch, and GetLatestLaunch are clearly differentiated by scope. The tool set is exceptionally well delineated.
The naming follows a mostly consistent pattern, but there is a notable inconsistency: seven tools use the Get* prefix (GetLaunch, GetVariantDetails, GetLintResults, etc.) while two use an inconsistent ApolloDocs* prefix (ApolloDocsSearch, ApolloDocsRead). The Get* tools are uniform, and the camelCase compound names (GetLatestLaunch, GetOperationMetrics) are readable, but the two ApolloDocs tools break the pattern.
13 tools is well within the ideal 3-15 range. Each tool maps to a distinct GraphOS capability: documentation access, identity resolution, launch/deployment inspection, health metrics, linting, PQL status, and variant details. No tool feels extraneous, and the count is appropriate for the broad but bounded domain of GraphOS observability and configuration.
The surface covers the core GraphOS operations well: deployments (launch tools), traffic health (metrics tools), configuration (variant/PQL/lint), documentation, and identity. A minor gap is the absence of write/management operations (e.g., no tool to trigger a launch, update PQL, or modify variant configuration), meaning the server is read-only in nature. For a read-only observability/health-check server this is acceptable, but an agent could not act on findings. Also no tool to list graphs/variants directly (only via GetMyIdentity).
