Skip to main content
Glama
Sign In
MarkIndex

MarkIndex

by jackjin1997
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_document_structure

Read-only

Retrieve a document's section outline—titles, line ranges, token counts, and summaries—without body text to locate relevant sections before reading their content.

Instructions

Get a document's section outline — node_id, title, line range, tokens, summary — without body text. REQUIRED for documents over 15000 tokens: call this first to locate the relevant sections, then read them with get_node_content(). Returns depth levels (default 2); nodes below the cut show child_count — pass their node_id to expand that subtree. Large outlines are split into parts: increment part until pagination.has_more is false.

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": {
      "doc_path": "<doc_path>"
    },
    "name": "get_document_structure"
  }
}

Input Schema

NameRequiredDescriptionDefault
partNoPart number for pagination (1-based, default 1). Increment until the response's `pagination.has_more` becomes false.
depthNoNumber of outline levels to return (1-10, default 2). Deeper nodes are summarized by `child_count`.
node_idNoExpand only the subtree of this node (depth counts from it). Copy it verbatim from a get_document_structure() or search_documents() result; omit for the whole document.
doc_pathYesLibrary-relative path of the document, copied verbatim from a browse_documents() or search_documents() result (case-sensitive, include the extension). Example: "guides/setup.md". Never construct one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so well: no body text is returned, depth controls truncation, sub-cut nodes collapse to child_count, and large outlines paginate via pagination.has_more. It stops short of noting any auth or size limits, but the output-shape and pagination behavior is unusually well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loaded with purpose, then the mandatory workflow, then truncation and pagination behavior. Every sentence carries information, though cramming four dense behaviors into one paragraph makes it slightly harder to scan than a short bulleted layout would.

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?

There is no output schema, and the description compensates fully by naming the returned fields, the child_count truncation signal, and the pagination flag. For a four-parameter read tool, an agent has everything needed to call it correctly and interpret the result.

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%, so baseline would be 3, but the description adds meaning the schema cannot: it explains the causal link between depth, the child_count placeholder, and node_id-based subtree expansion. The pagination instruction ('increment part until pagination.has_more is false') also ties the parameter to an output field.

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 ('Get a document's section outline') and enumerates what comes back (node_id, title, line range, tokens, summary) while explicitly excluding body text. That exclusion cleanly separates it from get_document and get_node_content.

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?

Gives an explicit trigger ('REQUIRED for documents over 15000 tokens'), an ordering rule ('call this first ... then read them with get_node_content()'), and the escalation path for truncated outlines via child_count/node_id. The alternative tool is named with the condition that selects it.

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

Deploy Server

Other Tools