Skip to main content
Glama
Sign In
MarkIndex

MarkIndex

by jackjin1997
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

browse_documents

Read-only

Lists Markdown library folders and documents so you can drill into subfolders and paginate results, locating answers by structure before resorting to keyword search.

Instructions

Primary discovery tool for the Markdown library. The bare call lists the library root: its sub-folders and the documents directly inside it (path, title, description, tokens). Pass folder to drill into a sub-folder level by level, and offset: next_offset to page through long listings. Browse first — do NOT jump to search_documents(): keyword search is an escalation path for when browsing and reading document structures have failed to locate the answer.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "browse_documents"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of documents to return per page (1-50, default 10).
folderNoFolder to list (default "", the library root). Library-relative folder path, copied verbatim from a `folders` entry of a browse_documents() response ("" = library root). Never construct one.
offsetNoZero-based pagination offset. Pass the value of `next_offset` from the previous response to fetch the next page.

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 declare readOnlyHint=true, and the description adds behavior beyond that: the bare call semantics, the folder-drilling model, and the returned fields with their pagination cursor. It stops short of stating limits on listing depth or what happens when a folder doesn't exist, but the essential call shape and precedence over search are 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?

Three sentences, front-loaded with the identity and return shape, then the parameter behavior, then the escalation rule. Slight redundancy with the schema on offset/next_offset, and the em-dash admonition is emphatic but justified given the risk of premature search.

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 three-optional-parameter read-only listing tool with no output schema, everything needed is present: what is returned, how to descend folders, how to page, and when a sibling tool becomes appropriate. No further structured data exists that the description neglects to compensate for.

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 the baseline is 3; the description still adds workflow meaning the schema lacks — that omitting folder lists the root and that folder should be traversed level by level from a returned folders entry, reinforcing the schema's 'never construct one' rule at the call level.

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 ('Primary discovery tool for the Markdown library') and enumerates exactly what a call returns (path, title, description, tokens for sub-folders and documents). It is clearly distinguishable from siblings like get_document_structure or get_node_content, which operate on a single document rather than listing a level.

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 explicit when-to-use ordering: browse first, escalate to search_documents() only after browsing and reading structures have failed. It also specifies the drill-down pattern (folder level by level) and pagination path (offset: next_offset), covering the main alternative-tool decision an agent faces.

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