Atlantic Agentic Labs

Read one documentation page

read_page

Read-onlyIdempotent

One public documentation page as Markdown, exactly as published, with its title, canonical URL, section and the date it last changed. Pass a path or URL that list_pages or a search result gave, such as "/mcp/public/" or "https://docs.atlanticagenticlabs.com/mcp/public/". Only pages of the public documentation site are served: any other address, and any page not in the published index, is refused. A very long page is truncated, with a note and the URL of the full 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": {
      "path": "<path>"
    },
    "name": "read_page"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	The page's path or full URL on docs.atlanticagenticlabs.com.

Output Schema

Name	Required	Description
`url`	Yes	The page's canonical URL. Cite this.
`note`	No
`path`	Yes
`title`	Yes
`section`	Yes
`markdown`	Yes	The page as Markdown, exactly as published (truncated when very long).
`truncated`	Yes
`characters`	Yes	The page's full length in characters.
`docs_version`	Yes
`last_updated`	Yes	When the page last changed (YYYY-MM-DD).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

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, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavior beyond them: refusal of off-site or unindexed addresses, and truncation of very long pages with a note and the URL of the full page. It does not discuss caching or freshness beyond the last-changed field, keeping it just 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.

Conciseness5/5

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

Four sentences, front-loaded with the return shape, then input sourcing, then the refusal boundary, then the truncation caveat. No sentence is redundant and each adds a distinct constraint.

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 single-parameter read tool with full annotations and an output schema, the description covers everything an agent needs: what comes back, where the input comes from, what is rejected, and how oversized results are handled.

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 100% and the single parameter is already documented, so the baseline is 3. The description adds meaning by clarifying that the parameter accepts either a relative path or a full URL and gives concrete examples of both forms, which the schema does not.

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 public documentation page) plus the exact return shape: Markdown, title, canonical URL, section, last-changed date. It also implicitly separates itself from list_pages and search_docs by positioning them as the producers of the path it consumes.

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 says to pass a path or URL obtained from list_pages or a search result, and states the exclusion boundary: only pages of the public documentation site that are in the published index are served, everything else is refused. That is both when-to-use and when-not-to-use guidance.

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

All Atlantic Agentic Labs tools Inspect

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.

Resources

Need Help?