Skip to main content
Glama

Radix Wiki

by wiki.radix
OverviewDiscussionsAdmin

Read a page

get_page
Read-onlyIdempotent

Read one page in full: its extracted text, current version number, update date and declared metadata. Takes either the whole path as one string (the url a listing returns works as-is) or the tagPath/slug pair it splits into — not a title. A wrong pair is answered with the tools that find a right one rather than an empty result. For the whole article set at once use get_full_corpus, and for a page as markdown fetch its URL with .md appended.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe whole path in one string, e.g. "contents/tech/core-concepts/utxo-model" — the form every listing returns as `url`. Use this or the tagPath/slug pair.
slugNoPage slug (e.g. "utxo-model"). Ignored when `path` is set.
tagPathNoTag path (e.g. "contents/tech/core-concepts"). Ignored when `path` is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / slug / description
      Previous value: -"Page slug (e.g. \"utxo-model\")"New value: +"Page slug (e.g. \"utxo-model\"). Ignored when `path` is set."
    • changedInput schema / properties / tagPath / description
      Previous value: -"Tag path (e.g. \"contents/tech/core-concepts\")"New value: +"Tag path (e.g. \"contents/tech/core-concepts\"). Ignored when `path` is set."
  2. Changed3 schema fields changed
    • addedInput schema / properties / path
      Added value: +{
+  "description": "The whole path in one string, e.g. \"contents/tech/core-concepts/utxo-model\" — the form every listing returns as `url`. Use this or the tagPath/slug pair.",
+  "type": "string"
+}
    • addedInput schema / requireOneOf
      Added value: +[
+  "path",
+  "slug"
+]
    • removedInput schema / required
      Removed value: -[
-  "tagPath",
-  "slug"
-]
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

While annotations already declare readOnlyHint and idempotentHint, the description adds substantial behavior beyond those fields: what fields the page includes, that a listing's `url` can be used as-is, that titles are not accepted, and that a wrong pair returns tool suggestions rather than an empty result. This gives the agent a clear picture of how the tool behaves in both success and failure cases.

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 compact and front-loaded: the first sentence states the core purpose, the second covers input forms, the third handles error behavior, and the fourth gives alternatives. Every sentence earns its place and no information is wasted.

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?

Even without an output schema, the description explains the return contents, input mechanics, failure behavior, and related tools. For a read-only, idempotent single-page fetch, this is complete enough for an agent to select and 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 coverage is 100%, and the schema already documents the three parameters and their precedence rules. The description adds value by clarifying that the path must be the listing-style URL and that a title is not a valid identifier, which helps the agent construct correct calls without needing to infer from the schema alone.

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 starts with a specific verb and resource: 'Read one page in full,' then enumerates exactly what is returned (extracted text, version number, update date, declared metadata). It is clearly distinguishable from siblings like list_pages and get_full_corpus because it targets a single page rather than a listing or the entire corpus.

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 gives explicit when-to-use guidance: it tells you to provide either the full path or the tagPath/slug pair, explicitly excludes titles as inputs, and explains what happens on a wrong pair. It also names the alternative for the whole corpus (get_full_corpus) and the markdown alternative, leaving no ambiguity about which tool fits a given need.

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

All Radix Wiki toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources