Atlas-Docs

get_docs_page

get_docs_page

Retrieve detailed documentation content for a specific page using its relative path to access technical information about libraries and frameworks.

Instructions

Retrieves a specific documentation page's content using its relative path. Use this to get detailed information about a known topic, after identifying the relevant page through get_docs_index or search_docs. Returns the complete content of a single documentation page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "docName": "<docName>",
      "pagePath": "<pagePath>"
    },
    "name": "get_docs_page"
  }
}

Input Schema

Name	Required	Description	Default
`docName`	Yes
`pagePath`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Jan 5, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool 'Retrieves' content (implying read-only) and returns 'complete content of a single documentation page', which adds useful context about behavior. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.

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 appropriately sized with three sentences, each earning its place: first states the purpose, second provides usage guidelines, third explains return behavior. It is front-loaded with the core function and avoids unnecessary 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?

Given no annotations, no output schema, and low schema coverage, the description does a decent job covering purpose and usage. However, it lacks details on return format (beyond 'complete content'), error cases, or parameter semantics, making it incomplete for a tool with such minimal structured data.

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?

Schema description coverage is 0%, so the description must compensate. It mentions 'relative path' which relates to 'pagePath', but does not explain 'docName' or provide any details on parameter formats, constraints, or examples. The description adds minimal value beyond the bare schema, failing to adequately cover the two undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Retrieves', 'get detailed information') and resources ('documentation page's content', 'relative path'). It distinguishes from siblings by specifying it's for a 'specific' page after using get_docs_index or search_docs, unlike get_docs_full or list_docs which likely handle broader scopes.

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 explicitly states when to use this tool ('after identifying the relevant page through get_docs_index or search_docs') and provides alternatives by naming sibling tools (get_docs_index, search_docs). It clearly defines the context for usage versus other tools.

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

Deploy Server