Skip to main content
Glama
angrysky56
by angrysky56

wiki_read_page

Read a wiki page from the vault, returning metadata, excerpt, or full content based on the selected mode.

Instructions

Read a wiki page.

Args: path: Relative path from vault root (e.g. 'wiki/concepts/rag.md'). mode: What to return: - "meta": metadata/frontmatter only (from index, 0 file reads) - "excerpt": metadata + first 500 characters of page body (from index) - "full": complete page content (reads file from disk)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoexcerpt
pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

The description makes clear this is a read operation and notes whether each mode reads from disk or an index, which gives some behavioral transparency. However, with no annotations, it does not mention error cases, missing paths, or permissions.

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 concise and well organized, using a short intro and bullet-like lines for mode values. No unnecessary words or redundant information.

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 provides enough to invoke the tool with correct parameters and understand the mode options, but does not discuss return format, potential errors, or how it relates to sibling read/search tools. Since an output schema exists, the lack of return detail is acceptable, but some contextual guidance is missing.

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?

Both parameters are covered in the description: path is defined as relative to the vault root, and mode lists all three accepted values with their return behavior. This adds meaningful detail beyond the bare 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?

The description clearly states the tool reads a wiki page, and the mode parameter specifies the level of content to return. It is distinct enough from sibling tools like wiki_search and wiki_list_pages, though it does not explicitly contrast them.

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?

The description explains the three modes and their performance implications, but does not explicitly state when to use this tool versus alternatives such as wiki_search or wiki_list_pages. Usage context is implied rather than stated.

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