Skip to main content
Glama
jgravelle
by jgravelle

index_repo

Index CSV, Excel, Parquet, and JSONL files from a GitHub repository to enable querying via column profiles, filters, and aggregations.

Instructions

Index data files from a GitHub repository. Discovers CSV, Excel, Parquet, and JSONL files, downloads them, and indexes each via the same pipeline as index_local. Datasets are named {owner}--{repo}--{filename}. Max 50 MB per file, 20 files per repo. Set GITHUB_TOKEN env var for private repos or to avoid rate limits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesGitHub repo URL or owner/repo string (e.g. 'pandas-dev/pandas' or 'https://github.com/pandas-dev/pandas')
incrementalNoSkip re-index if HEAD SHA unchanged (default true)
github_tokenNoGitHub token override (defaults to GITHUB_TOKEN env var)
Behavior4/5

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

Annotations only signal readOnlyHint=false, so the description carries the burden of disclosing side effects. It explicitly states the tool downloads and indexes files, includes size/count limits, and explains token usage for private repos/rate limits. It does not mention overwrite or re-indexing side effects, but the incremental parameter hints at that behavior.

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 four sentences, front-loaded with purpose, and every sentence contributes meaningful information (file types, pipeline, naming, limits, token). No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (GitHub discovery, limits, auth, naming), the description covers essential operational details well. It lacks explicit post-index return behavior, but no output schema exists and the primary effect is indexing, so this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage with clear parameter descriptions (url, incremental, github_token), so the baseline is 3. The description adds minimal parameter-specific context (e.g., GITHUB_TOKEN env var reference) but does not go beyond what the schema already provides.

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 opens with a specific verb+resource ('Index data files from a GitHub repository'), then details the discovery and indexing process, supported file types, and dataset naming convention. This clearly distinguishes it from sibling index_local by specifying the remote source and naming scheme.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: GitHub repository, file types, size limits, and auth requirements. It mentions 'same pipeline as index_local' but does not explicitly state when to use this over index_local or provide exclusions, so it stops short of full alternative guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jgravelle/jdatamunch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server