Skip to main content
Glama
Sign In
mcp-retrieve

mcp-retrieve

by maxbaluev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

index_folder

Index all text files in a local folder by splitting into chunks and embedding them for retrieval. Replaces any existing index.

Instructions

Index all text files under a local folder for retrieval.

Reads supported text files recursively, splits them into overlapping chunks, and embeds each chunk into a multi-vector representation. Re-indexing replaces any previous index. Returns the number of files and chunks indexed.

Args: folder: Path to a local directory to index.

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": {
      "folder": "<folder>"
    },
    "name": "index_folder"
  }
}

Input Schema

NameRequiredDescriptionDefault
folderYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description fully discloses behavior: recursive reading, splitting, embedding, re-indexing replacement, and return values. Minor gap: no mention of whether the tool requires write 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?

Two concise paragraphs with an args list, front-loaded purpose, no fluff.

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?

Given a simple single-param tool with output schema, the description covers all necessary behavioral and return value aspects.

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?

The 'Args' section clarifies the 'folder' parameter as a path to a local directory, adding meaning beyond the schema's bare type. Could specify path format but sufficient for a single required param.

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 clearly states the tool indexes all text files under a local folder for retrieval, with a specific verb and resource. It distinguishes from the sibling 'search' by implying this is the indexing step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly suggests using this before search, but does not explicitly state when to use vs alternatives, nor any exclusions or prerequisites.

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